Skip to content

SYSTEM Cited by 3 sources

AgentCore Policy

What it is

AgentCore Policy is the Bedrock AgentCore surface that enforces deterministic, Cedar-based access control over agent tool invocations — independent of what the model reasons or decides. It sits alongside the Gateway and defines which agent sessions may invoke which tools.

Cedar is AWS's open-source policy language for fine-grained, verifiable authorization decisions; Policy uses it so authorization is evaluated by a rules engine, not inferred by the LLM.

Why it exists

In a model-driven agent, the model chooses which tools to call — so hard constraints cannot live in the prompt or an orchestration graph. Policy makes the constraint mechanical:

"Policy in Amazon Bedrock AgentCore enforces deterministic access control independently of model reasoning." — AgentFlo (Source: sources/2026-08-20-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore)

Example rule: a sales agent can't call customer-support-only APIs, regardless of what the conversation or a prompt-injection attempt tries to make it do.

Guardrails embedding

Bedrock Guardrails can be embedded in Policy to filter prompt attacks, harmful content, and sensitive information on both requests and responses — layering content-safety filtering on top of tool-authorization rules.

Relation to Gateway and Identity

  • Policy decides which session may invoke which tool (deterministic authorization).
  • Gateway executes the tool call once allowed and holds credentials centrally (patterns/central-proxy-choke-point).
  • Identity authenticates the agent identity behind those decisions.

Forbid-wins semantics and tier mapping (2026-08-26)

In AWS's graduated autonomy architecture, Policy is the deterministic enforcement layer that maps an agent's autonomy tier to a Cedar policy state, exploiting Cedar's forbid-wins composition — one satisfied forbid overrides any number of permits (deny-wins-policy-composition) (Source: sources/2026-08-26-aws-closing-the-ai-agent-trust-gap-with-graduated-autonomy):

  • Probation — a forbid policy blocks write/execute/delete tool actions.
  • Promotion — the forbid policy is removed and broader permits take effect.
  • Demotion — the forbid policy is re-applied.

Because Gateway in enforce mode lists only tools policy could permit, a tier's unconditional forbids keep blocked tools out of the agent's tool listing altogether. Cedar denies by default, so enforcement never depends on the agent choosing to behave. A single Cedar deny-all policy implements the emergency stop — denying all tool invocations within seconds, no redeploy — and is out of band, evaluated outside the agent's process.

Caveats

  • Architecture-level disclosure only. The AgentFlo post names Policy's role (Cedar-based, deterministic, tool-scoped, Guardrails-embeddable) but not its internal evaluation model, latency, or policy-authoring workflow.

Seen in

  • sources/2026-08-20-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore — Cedar-based deterministic tool authorization for AgentFlo's agents (e.g. sales agent barred from support-only APIs), with Bedrock Guardrails embeddable in Policy for request/response content filtering.

  • sources/2026-08-21-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore-part-2 — Part 2 details Policy as the during-tool-execution layer of AgentFlo's three-layer guardrails: Cedar rules enforce business constraints (max discount %, tool scope) independent of model reasoning, and integrate with Bedrock Guardrails to run prompt-attack detection / content filtering / sensitive-info blocking at the gateway boundary.

  • sources/2026-08-26-aws-closing-the-ai-agent-trust-gap-with-graduated-autonomy — Policy as the deny-by-default enforcement layer of graduated autonomy: tier mapped to Cedar forbid state (probation forbids write/execute/delete; promotion removes it; demotion re-applies), forbid-wins semantics, tool-listing restricted to permitted tools, and a Cedar deny-all emergency stop.

  • sources/2026-09-11-aws-from-zero-shot-forecast-to-purchase-order-with-agentcore — Policy guards what writes reach external systems, paired with the Gateway (Gateway validates who is calling via Cognito JWT; Policy decides whether this call is allowed via Cedar). Two rules on the single registered write tool save_decision: allow_write_reporting_only (only the Reporting workflow identity may call it) and deny_high_value_orders — a forbid on context.input.budget_used > 50000 regardless of principal. Key insight: the deny is meaningful only at the write boundary — putting it upstream on calculate_order would be ineffective because the agent could re-run the calculation until it passed and the denial wouldn't map to any durable effect.
Last updated · 766 distilled / 2,225 read