Skip to main content

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 organisation 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 permissionjustification
s3:GetObjectRead application packet documents from the designated S3 input bucket only.
s3:PutObjectWrite the final output JSON payload to the designated S3 output bucket only.
bedrock:InvokeModelCall a specific, approved foundation model within Amazon Bedrock. Scoped to specific model ARNs — the agent cannot invoke other Bedrock models.
bedrock:ApplyGuardrailApply your configured Bedrock Guardrail policy to agent inputs and outputs. Required for all inference invocations.
sqs:ReceiveMessagesqs:DeleteMessageReceive work items from the designated SQS intake queue and acknowledge completion.
logs:CreateLogStreamlogs:PutLogEventsWrite structured audit logs to the designated CloudWatch Log Group.
kms:DecryptDecrypt 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 assignmentscope
Storage Blob Data ReaderDesignated input storage container only
Storage Blob Data ContributorDesignated output storage container only
Cognitive Services OpenAI UserSpecific Azure OpenAI resource used for inference
Key Vault Secrets UserDesignated Key Vault for decryption keys
Monitoring Metrics PublisherDesignated 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:

Topic Denial Policies

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).

PII Redaction

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.

Hallucination Filtering (Grounding Checks)

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.

Prompt Injection Protection

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.

Toxicity & Harm Filtering

Standard Bedrock Guardrail content policies filter harmful or inappropriate content from both model inputs and outputs across all agent sessions.

Custom Blocklists

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.
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.