Governance: Policy, Guardrails & IAM

A production agent is not secured by one knob. AgentCore stacks five independent layers (auth itself has an inbound and an outbound half), each catching a different class of failure. Read them as defense in depth — any one can be bypassed; together they are hard to defeat:

The distinction this lesson keeps returning to: auth answers "who are you and may you call this agent at all," governance answers "given that you got in, may you make this specific tool call." Guardrails are orthogonal again — they inspect content, not identity or actions. You want all three.

Guardrails reason about content. AgentCore Policy reasons about actions — deterministically. It is the layer that decides whether a given tool call is permitted, and it does so by intercepting every Gateway tool call before execution.

The engine is built on Cedar — AWS's open-source policy language (the same language behind Amazon Verified Permissions). You author rules in one of two ways:

• Cedar directly — precise, version-controllable permit/forbid statements.
• Natural language — describe the rule in English and let Policy compile it. (Natural-language authoring is billed per-token; Cedar evaluation is billed per authorization request — both [VOLATILE], verify the live pricing page.)

You attach Policy to a Gateway through policyEngineConfiguration, which has exactly two enforcement modes:

# boto3: bedrock-agentcore-control
policyEngineConfiguration = {
    "mode": "ENFORCE",   # or "LOG"
    "arn": "arn:aws:bedrock-agentcore:us-east-1:111122223333:policy-engine/orders-engine"
}

The LOG → ENFORCE progression is the safe rollout pattern: ship a policy in LOG, watch the would-be denials in your logs for a few days, fix false positives, then flip to ENFORCE. The Cedar schema for a policy engine has a size budget (~400 KB per policy engine [VOLATILE]) that grows with the number of tools and parameters it reasons over — large tool catalogs need attention here.

Policy is declarative. When you need imperative logic at the gateway — rewrite a request, inject a header, call out to a risk service, redact a field — you use a gateway interceptor: a custom Lambda that runs per invocation at a defined interception point.

# boto3: attach an interceptor when creating/updating a gateway
interceptorConfigurations = [
    {
        "interceptor": {"lambda": {"arn": "arn:aws:lambda:us-east-1:111122223333:function:gw-guard"}},
        "interceptionPoints": ["REQUEST"]
    }
]

The interceptor Lambda sees the invocation and can transform or reject it before the target tool is called — think of it as middleware in the gateway request path. Policy (declarative Cedar) and interceptors (imperative Lambda) compose: let Cedar express the allow/deny rules, and reserve interceptors for the dynamic checks Cedar can't express.

Scoping what Memory an agent can read is a separate, IAM-level control. AgentCore Memory uses namespaces — hierarchical, slash-delimited paths with template variables like {actorId}, {sessionId}, and {memoryStrategyId}. You can pin IAM permissions to those namespaces with two condition keys:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "bedrock-agentcore:RetrieveMemoryRecords",
    "Resource": "*",
    "Condition": {
      "StringLike": { "bedrock-agentcore:namespacePath": "/users/${aws:PrincipalTag/actorId}/preferences/*" }
    }
  }]
}

This lets one shared Memory store serve many actors while IAM guarantees an agent can only retrieve records inside its own namespace subtree — least privilege applied to long-term memory.

Where Policy governs actions, Bedrock Guardrails govern content — and they span models, not just Bedrock-hosted ones. A guardrail covers five concerns: content filters, denied topics, word filters, PII detection/redaction, and contextual grounding. There are two ways to apply them.

Native (Bedrock-model-specific). Attach the guardrail to the model. On a Strands BedrockModel you set guardrail_id, guardrail_version, guardrail_trace, and redaction controls, then detect a firing by inspecting the stop reason:

from strands.models import BedrockModel

model = BedrockModel(
    model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0",  # [VOLATILE] verify default model id
    guardrail_id="abcd1234",
    guardrail_version="DRAFT",
    guardrail_trace="enabled",
)
# A blocked turn surfaces as:
# response.stop_reason == "guardrail_intervened"

Model-agnostic (imperative). When the model is not a Bedrock FM — OpenAI, Gemini, a self-hosted model — call the standalone ApplyGuardrail API to moderate text without invoking any FM:

import boto3
bedrock_runtime = boto3.client("bedrock-runtime")

result = bedrock_runtime.apply_guardrail(
    guardrailIdentifier="abcd1234",
    guardrailVersion="DRAFT",
    source="INPUT",                      # or "OUTPUT"
    content=[{"text": {"text": user_message}}],
)
# inspect result['action'] / result['outputs'] before passing text to the model

Shadow mode mirrors the LOG idea from Policy: using Strands Hooks on MessageAddedEvent / AfterInvocationEvent, you can log would-be blocks before enforcing them, so you measure a guardrail's impact on real traffic before it can refuse a user.

These two are constantly conflated, so draw the line sharply:

• IAM governs AWS-level access. Who may call the control-plane (bedrock-agentcore-control) and data-plane (bedrock-agentcore) APIs, create credential providers, use KMS keys, and what the agent execution role is allowed to do. SigV4 is one inbound auth option here.
• AgentCore Identity governs agent/workload identity. Each agent gets a first-class workload identity (ARN arn:aws:bedrock-agentcore:<region>:<account>:workload-identity/directory/default/workload-identity/<agent-name>) plus a token vault that holds OAuth tokens and API keys for non-AWS services (Google Drive, GitHub, Slack, internal APIs) — 2LO (machine-to-machine) and 3LO (user-delegated).

A one-line mnemonic: IAM is how AWS knows the agent; Identity is how the agent reaches everything that isn't AWS.

The key IAM actions you must know:

{
  "Effect": "Allow",
  "Action": [
    "bedrock-agentcore:InvokeAgentRuntime",
    "bedrock-agentcore:GetWorkloadAccessTokenForJWT",
    "bedrock-agentcore:GetResourceOauth2Token"
  ],
  "Resource": "arn:aws:bedrock-agentcore:us-east-1:111122223333:runtime/my-agent-*"
}

A hardened AgentCore deployment layers all of the above. Walk this list when you design or review one:

• Isolation — rely on the per-session microVM, but treat it as isolation, not an egress firewall. Pair with least-privilege roles and monitoring.
• Inbound auth — SigV4 or JWT/OIDC on Runtime and Gateway. A runtime supports SigV4 or JWT, not both — create separate versions. Reserve InvokeAgentRuntimeForUser for tightly-scoped delegation.
• Outbound auth + token vault — no secrets in code or LLM context. Use @requires_access_token / @requires_api_key; the vault enforces per-(agent + user) isolation and auto-refreshes tokens.
• Governance — AgentCore Policy in LOG first, then ENFORCE; gateway interceptors for imperative checks; namespace-scoped IAM on Memory so a shared store can't leak across actors.
• Guardrails — Bedrock Guardrails (native on BedrockModel, or ApplyGuardrail for non-Bedrock models) for content filters, denied topics, PII, and grounding; shadow-mode them before enforcing.
• Auditability — emit APPLICATION_LOGS (full request/response payloads + trace/session IDs) to CloudWatch Logs / S3 / Data Firehose, and watch CloudTrail. Filter PII and secrets before emission — full payloads include user content.

No single layer is sufficient. Auth without governance lets an admitted agent run wild; governance without guardrails lets it emit toxic content; everything without auditability leaves you blind in an incident. Stack them.