Skip to main content

Bounded Autonomy: Policy Engine

Who this is for

Builders who have a working workflow agent and are ready to add Cedar policy guardrails. If you're still picking a pattern, start with the workflow overview.

The single most important differentiator for production workflow agents. Without policy enforcement, an agent with access to infrastructure tools is a liability. With it, the agent operates within a provable boundary.

Why This Matters​

Without bounded autonomy, you get one of two outcomes:

  • Over-permissive agents that can cause outages when they make mistakes
  • Under-permissive agents that require human approval for every action, defeating the purpose of automation

Cedar policies let you precisely define the boundary. The agent reasons freely within its allowed actions, and the platform prevents it from exceeding them, regardless of what the LLM decides. Deny always wins over permit — multiple policies compose safely, and an explicit forbid overrides any permit.

Capabilities​

CapabilityDetail
Tool-level access controlAllow or deny specific tools based on Cedar policies.
Combined schema sizeThe Cedar schema generated from a policy engine's associated gateways is capped at 400 KB, driven by tool count and input-parameter complexity rather than policy count. Gateways with a very large or complex tool catalog may need a dedicated policy engine. See the AgentCore limitations reference.
Condition-based enforcementRestrict tool use based on request context (time, entity type, priority).
LOG_ONLY vs ENFORCE modesStart with LOG_ONLY to observe decisions; switch to ENFORCE for production.
Audit trailEvery policy evaluation is logged with full context in CloudWatch.
Multi-policy compositionCombine multiple policies. Deny always wins over permit.

Autonomy Risk Classification​

Before writing policies, classify each action's risk level using the Agentic AI Security Scoping Matrix. This gives you a systematic basis for deciding which actions need condition-based gating, human approval, or time-windowing.

Example: Priority-Based Autonomy​

// High-priority incidents: allow remediation actions
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RemediationTools___restart_service",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/incident-gateway"
)
when {
  context.input.priority == "HIGH"
};

// Low-priority: only allow read-only diagnostic tools
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"DiagnosticTools___get_metrics",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/incident-gateway"
)
when {
  context.input.priority == "LOW"
};

Policy Design Patterns​

PatternDescriptionExample
Priority-gatedDifferent tool access based on event severityHIGH = remediate, LOW = diagnose only
Time-windowedAllow destructive actions only during maintenance windowsRestarts only between 2-4 AM UTC
Entity-scopedRestrict actions to specific resource types or namespacesOnly restart services in staging namespace
Escalation ladderAuto-execute low-risk, require approval for high-riskAuto-restart → human-approve failover
Read-first, act-on-confirmAgent can read anything, but write actions need policy permitGet metrics freely; restart needs explicit permit

LOG_ONLY vs ENFORCE​

Start in LOG_ONLY mode to understand your agent's decision patterns before constraining it:

  1. LOG_ONLY — Policies are evaluated but not enforced. Violations are logged but the agent proceeds. Use during development and initial production deployment to build confidence.
  2. ENFORCE — Policies are evaluated and enforced. The agent cannot exceed its permitted actions. Switch to this once you've validated the policy set against real traffic.

Policy evaluation logs in CloudWatch show every evaluation decision — use them during the LOG_ONLY phase to identify gaps before switching to ENFORCE.

Deployment Workflow​

  1. Classify risk — Use the Agentic AI Security Scoping Matrix to determine which actions need conditions or human approval.
  2. Define policies — Write Cedar policies that match your organization's autonomy boundaries.
  3. Deploy in LOG_ONLY — Observe the agent's behavior against real events. Review policy evaluation logs.
  4. Tune policies — Adjust based on false positives (blocking legitimate actions) and false negatives (allowing unintended actions).
  5. Switch to ENFORCE — Once satisfied, flip to enforcement mode. The agent is now bounded.
  6. Iterate — As you add new tools or domains, add corresponding policies before granting access.

Further Reading​