hidekazu-konishi.com

Amazon Bedrock AgentCore Cedar Policy Builder and Tester - Client-Side Cedar Authorization Policy Editor and Evaluator

First Published: 2026-06-24
Last Updated: 2026-06-24

Features

• Builder: Compose a Cedar policy from a form - permit / forbid, principal (is <type> / == entity / any), action (single / list / any), resource Gateway, and when / unless conditions - with a live-generated policy you can copy, download, or send to the Tester.
• Tester: Register one or more policies and a sample authorization request (principal type and id, JWT-claim tags, action, Gateway ARN, and context.input parameters), then evaluate the decision.
• Default-deny and forbid-overrides-permit: The evaluator applies Cedar's semantics - all actions are denied unless an explicit permit matches, and any matching forbid wins.
• Evaluation trace: Every policy is traced as MATCH / no match / INDETERMINATE, with per-element reasons for principal, action, resource, and each condition.
• Validator / lint: Structural checks plus AgentCore-specific conventions (principal types AgentCore::OAuthUser / AgentCore::IamEntity, resource AgentCore::Gateway, <Target>___<tool> action naming), hasTag guard checks, and always-allow / always-deny hints.
• AgentCore-shaped examples: Default-deny + scoped permit, forbid-wins, context conditions, and IAM-principal presets.
• 100% client-side: No network calls, no account required, works offline after first load.

How to Use

1. In the Builder tab, set the effect, principal, action, and resource, add any when / unless conditions, and watch the generated Cedar policy update live. Click Add to Policy Set, Copy Policy, or Download .cedar.
2. In the Tester tab, click a Sample Policies button to load an example, or paste your own policies. Use + Add Policy for more.
3. Fill in the Authorization Request: principal type and id, the action (the tool being invoked, e.g. RefundTool___process_refund), and the Gateway ARN.
4. Add Principal tags (JWT claims) and Context input (tool parameters) referenced by your conditions.
5. Click Evaluate. The badge shows ALLOW or DENY, with the deciding policy, the default-deny note, any approximation caveats, and a full per-policy trace.
6. Switch to the Validator tab and click Validate Policy Set to lint the same policies.

About This Tool

Cedar is an open-source policy language created by AWS for writing and enforcing authorization policies. Policy in Amazon Bedrock AgentCore uses Cedar to provide deterministic, externally enforced authorization for AI agents: policies are evaluated by a policy engine and enforced at the AgentCore Gateway, which intercepts every agent-to-tool invocation. Because the policy decision is made outside the agent, the (non-deterministic) large language model cannot circumvent it.

Evaluation semantics follow Cedar exactly: all actions are denied by default; the engine uses forbid-overrides-permit (any matching forbid means DENY; at least one matching permit with no matching forbid means ALLOW; otherwise default deny). An unless on a forbid only narrows where that forbid applies - it never grants access and never overrides a permit. In AgentCore, policies are validated against a Cedar schema auto-generated from the Gateway's tool definitions, and the policy engine can run in ENFORCE or LOG_ONLY mode.

AgentCore authorization and Cedar syntax were verified against the official AWS and Cedar documentation as of 2026-06-23. Specifications change; always re-check the official docs.

FAQ

What does "default deny" mean in AgentCore Policy?
Every tool invocation is denied unless a policy explicitly permits it. If no policy matches a request, the result is DENY. You must write explicit permit policies to allow specific principals to invoke specific tools.

permit vs forbid - which wins?
forbid wins. Cedar uses forbid-overrides-permit: if any forbid policy matches, the decision is DENY regardless of any matching permit. ALLOW happens only when at least one permit matches and no forbid matches.

How does Amazon Bedrock AgentCore use Cedar?
AgentCore stores Cedar policies in a policy engine and enforces them at the AgentCore Gateway. For every agent-to-tool request, the engine evaluates the applicable policies and allows or denies the tool call - independent of the agent's own reasoning. The principal is an OAuth user or IAM entity, the action is the tool invocation, and the resource is the Gateway.

What are principal tags and context.input in an AgentCore Cedar policy?
For AgentCore::OAuthUser, the JWT token's claims (such as username, role, scope) are exposed as tags and read with principal.getTag("...") (guard with principal.hasTag("...")). The tool's input parameters are available as context.input.<param>, so conditions can constrain calls based on arguments (for example, context.input.amount < 500).

Is this tool's evaluation authoritative?
No. It is a best-effort, approximate evaluator for learning and drafting. It models Cedar's scope matching and default-deny / forbid-wins semantics and a common subset of when / unless conditions, but it is not a complete Cedar engine and does not call AWS. Constructs it cannot evaluate are reported as INDETERMINATE. Always validate with the official AgentCore and Cedar tooling before relying on a policy.

Related Tools

• IAM Policy Simulator (Offline) - Client-Side AWS IAM Policy Evaluator - evaluate AWS IAM identity-based and resource-based policies locally.
• AWS Policy Diff Tool - compare two AWS policy documents and highlight differences.
• JSON Formatter Tool - format and validate JSON, useful for inspecting tool schemas and request payloads.

Related Articles

• Amazon Bedrock AgentCore Policy Implementation Guide
• Amazon Bedrock AgentCore Beginners Guide

Important Notes

• Approximate, not authoritative. This tool builds Cedar policies and provides a best-effort, approximate evaluation for learning and drafting. It is not a complete Cedar evaluator and does not call AWS. AgentCore authorization and Cedar syntax were verified against official documentation as of 2026-06-23; always validate policies with the official tooling before relying on them.
• Modeled subset. The evaluator handles scope matching (principal is / ==, action == / in [list], resource ==), default-deny, forbid-overrides-permit, and a common subset of conditions (boolean logic, comparisons, hasTag / getTag, context.input, like). Group / set membership (in), set and IP and decimal and datetime functions, and if-then-else are not evaluated and are reported as INDETERMINATE.
• Schema-aware validation is not performed. Real AgentCore validates policies against a Cedar schema auto-generated from the Gateway's tool definitions; this tool cannot know your Gateway's tools, parameter types, or available context fields.
• No secrets. Use placeholder identifiers (sample account IDs, ARNs, and claim values). Do not paste real tokens; nothing is stored or transmitted, but treat the page as a drafting surface.
• Authoritative tooling: use the AgentCore policy authoring, validation, and analysis features and the official Cedar tooling to confirm behavior before deployment.