> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uselayerup.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Identity, Access & AI Guardrails
> Least-privilege IAM model for AWS and Azure, native AI guardrail configuration, and the principle that the agent introduces no new security surface — it operates within the perimeter you already own.
# 3 — Identity, access & AI guardrails — least-privilege IAM, governed inference & native safety controls.
This section directly addresses the requirements of your Information Security, Compliance, and Legal teams. Every security control layer described here maps to the specific cloud-native tooling your organization already owns and operates. The Layerup agent does not introduce a net-new security perimeter — it operates within the perimeter you have already established.
***
## 3.1 Identity and access management — least privilege by design
The Layerup agent container is never granted broad administrative access to your AWS or Azure account. It operates under the principle of least privilege: assigned only the specific permissions required to perform its defined workflow functions. Everything else is explicitly denied.
### 3.1.1 AWS IAM Execution Role
A dedicated IAM Execution Role is created for the Layerup agent task. The representative least-privilege policy is as follows:
| IAM permission | justification |
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `s3:GetObject` | Read application packet documents from the designated S3 input bucket only. |
| `s3:PutObject` | Write the final output JSON payload to the designated S3 output bucket only. |
| `bedrock:InvokeModel` | Call a specific, approved foundation model within Amazon Bedrock. Scoped to specific model ARNs — the agent cannot invoke other Bedrock models. |
| `bedrock:ApplyGuardrail` | Apply your configured Bedrock Guardrail policy to agent inputs and outputs. Required for all inference invocations. |
| `sqs:ReceiveMessagesqs:DeleteMessage` | Receive work items from the designated SQS intake queue and acknowledge completion. |
| `logs:CreateLogStreamlogs:PutLogEvents` | Write structured audit logs to the designated CloudWatch Log Group. |
| `kms:Decrypt` | Decrypt application data from S3 using the designated customer-managed KMS key. Cannot rotate, disable, or delete keys. |
The IAM Role is explicitly denied all other permissions via a deny-all default policy. It cannot access other S3 buckets, invoke EC2 APIs, access Secrets Manager secrets outside its designated path, or make any calls to services outside those listed above. This is enforced at the AWS IAM layer — not by agent configuration.
No Layerup personnel hold any IAM credentials in your AWS account at any time during production operation. Layerup's involvement during the implementation engagement is performed via a time-limited, audited role that is explicitly revoked upon production go-live.
### 3.1.2 Azure Managed Identity
The Azure equivalent is a User-Assigned Managed Identity attached to the Container App or AKS Pod. Your Azure RBAC assignments scope this identity to:
| RBAC assignment | scope |
| -------------------------------- | ------------------------------------------------- |
| `Storage Blob Data Reader` | Designated input storage container only |
| `Storage Blob Data Contributor` | Designated output storage container only |
| `Cognitive Services OpenAI User` | Specific Azure OpenAI resource used for inference |
| `Key Vault Secrets User` | Designated Key Vault for decryption keys |
| `Monitoring Metrics Publisher` | Designated Azure Monitor workspace |
The identity has no subscription-level roles and cannot access any resources outside those explicitly scoped by your Azure RBAC configuration.
***
## 3.2 Native AI guardrails — your controls, applied at inference time
Your team retains full control over the AI safety boundaries applied to the Layerup agent at inference time. These guardrails are configured and managed entirely by your platform team using native cloud tooling — Layerup does not configure, manage, or bypass these policies.
### 3.2.1 AWS: Amazon Bedrock Guardrails
Amazon Bedrock Guardrails are applied as a middleware layer between the Layerup agent's prompt construction and the foundation model's response. Your team configures the following policy types within the Bedrock Guardrail:
Block the model from discussing topics outside the defined scope of the agent's configured workflow (e.g., preventing the model from generating investment advice or medical diagnoses outside its underwriting remit).
Automatically detect and redact personally identifiable information (SSNs, Date of Birth, medical record numbers) from model inputs and outputs where not required for the workflow. Guardrail-applied PII handling is auditable and consistent across all agent sessions.
Bedrock Guardrails support grounding checks that evaluate whether the model's output is factually consistent with the provided source documents — providing an independent verification layer on top of the agent's own source-citation requirement.
Content classifiers detect and block prompt injection attempts — inputs crafted to override the agent's operating instructions. Every inference call is screened before the model processes it.
Standard Bedrock Guardrail content policies filter harmful or inappropriate content from both model inputs and outputs across all agent sessions.
Your team can configure domain-specific blocked terms or content patterns beyond the standard guardrail defaults — for example, blocking specific claim-related terms that should never appear in model outputs.
### 3.2.2 Azure: Azure AI Content Safety
On Azure, the equivalent is Azure AI Content Safety, integrated into the Azure AI Foundry orchestration layer:
* **Harm category classifiers** (hate, violence, self-harm, sexual content) are applied at the prompt and completion layers for every inference call.
* **Prompt Shield** blocks jailbreak and indirect prompt injection attacks before the model processes the input.
* **Custom blocklists** can be configured by your team to add domain-specific terms or patterns to the filtering ruleset.
* Content Safety is applied consistently to every inference request made by the agent — there is no code path that bypasses the filter.
```mermaid theme={null}
flowchart LR
AGT[Agent Container] -->|"constructs prompt + AOP context"| GRL
subgraph guardrail ["Guardrail Layer — Your Configuration"]
GRL[Bedrock Guardrails
or Azure AI Content Safety]
subgraph checks ["Applied Policy Checks"]
C1[Topic Denial]
C2[PII Redaction]
C3[Prompt Injection Block]
C4[Grounding Check]
C5[Harm Filtering]
end
GRL --> C1 & C2 & C3 & C4 & C5
end
C1 & C2 & C3 & C4 & C5 -->|"all pass → forward to model"| LLM[Foundation Model
Bedrock / Azure OpenAI]
LLM -->|"response → re-screened"| GRL2[Guardrail Output Screen]
GRL2 -->|"cleared response"| AGT
C3 -->|"injection detected → block + log"| ESC[Escalate to Human Review]
classDef layer fill:#fafafa,stroke:#111,color:#111;
classDef check fill:#f4f4f2,stroke:#111,color:#111;
class guardrail,checks layer;
class C1,C2,C3,C4,C5 check;
```
*Fig. A3.1 — Guardrail enforcement flow. Every inference call passes through your configured guardrail policies before reaching the foundation model, and again on the model's response. A guardrail block triggers human escalation — the agent does not retry past a block.*