AWS Bedrock AgentCore Runtime went GA in October 2025. AgentCore Policy followed in March 2026. Here is how the complete governed agent stack assembles — layer by layer — for platform teams in banking and insurance.
Platform teams at AWS-native financial institutions have been watching the agentic AI space and asking the same question: "When the managed services are ready, can we build a governed agent stack without custom middleware?" As of early 2026, the answer is yes. AWS Bedrock AgentCore Runtime, which went GA in October 2025, and AWS AgentCore Policy, which followed in March 2026, together provide the enforcement, identity, and audit infrastructure that governed agent deployment requires.
The challenge before these services was real: organizations that wanted to deploy AI agents in production needed to either use a third-party orchestration framework (LangChain, CrewAI, AutoGen) with custom governance wrapping, or build their own agent runtime infrastructure from scratch. Neither option was operationally attractive for regulated industries where the governance overhead of custom software is itself a compliance burden. AWS AgentCore changes the calculus by providing managed infrastructure with governance built in.
This post describes the complete AWS reference architecture for governed agent deployment, layer by layer, with specific attention to how each component addresses the governance requirements that compliance teams and InfoSec architects care about. We also note where this architecture compares to the Azure APIM enforcement pattern covered in the Day 4 post of this series, for organizations evaluating both platforms.
AWS Bedrock AgentCore is a managed service that provides the runtime infrastructure for deploying, executing, and governing AI agents built on foundation models available in Amazon Bedrock. It addresses the operational gap that existed between Bedrock's model invocation APIs — which allow you to call a foundation model — and the production requirements of an agent that needs to maintain session state, invoke external tools, track execution history, and respect governance policies.
AWS Bedrock AgentCore Runtime, generally available as of October 2025, is the managed execution environment for AI agents on AWS. It provides: agent lifecycle management (creation, versioning, deployment, and deprecation), tool execution infrastructure (managed invocation of tools defined in the agent's tool configuration), session state management (maintaining conversation context across turns), and integration with AWS governance services including IAM, CloudWatch, and the AgentCore Gateway/Cedar Policy enforcement layer.
The key difference between AgentCore Runtime and earlier Bedrock Agents functionality is the depth of the governance integration. Earlier Bedrock Agents provided basic tool invocation; AgentCore Runtime provides full agent lifecycle management with audit logging, version control, and integration points for the Cedar Policy enforcement layer that was added in March 2026. For platform teams in regulated industries, the governance integration is the critical change.
AWS AgentCore Gateway is the traffic management layer that sits between an agent's intention (the tool call it wants to make) and the actual execution of that tool call. Every tool call an agent attempts passes through the Gateway, where it is evaluated against Cedar policies before execution proceeds. Cedar is Amazon's open-source attribute-based access control (ABAC) language — it defines policies in terms of the agent's identity, the requested action, the target resource, and the context of the request.
Cedar is an open-source policy language developed by AWS for expressing attribute-based access control (ABAC) decisions. Cedar policies specify conditions under which a principal (such as an AgentCore agent) may perform an action (such as invoking a tool) on a resource (such as a payment API), given contextual attributes (such as transaction amount, customer tier, or time of day). Cedar is designed for correctness and auditability: policies are formally verifiable and the decision reasoning for each authorization is available for logging. AWS AgentCore Policy uses Cedar to gate every tool call in the AgentCore Runtime.
The governance value of Cedar Policy enforcement is that it is preventive, not detective. Traditional security monitoring detects anomalies after an agent has already taken an action. Cedar Policy enforcement prevents the action from executing in the first place if it violates policy. For a financial services organization where an incorrect payment or unauthorized data access cannot be easily reversed, the distinction between "we detected it" and "we prevented it" is significant.
In practice, Cedar policies for agent governance express rules like: "Agent payment-processor-v2 may invoke the refund API only for amounts less than $500 and only during business hours" or "Agent customer-data-agent may read customer records but may not modify or delete them." These policies are managed centrally, versioned, and audited independently of the agent's model — meaning a policy change doesn't require redeployment of the agent, and a model update doesn't inadvertently change the policy.
Bedrock Guardrails and Cedar Policy operate at different layers of the agent stack and are complementary rather than redundant. Cedar Policy operates at the tool call layer — it governs what tools the agent may invoke and under what conditions. Bedrock Guardrails operates at the model input/output layer — it governs what content the agent may receive from users and what content it may output, regardless of which tool is eventually called.
Bedrock Guardrails provides three protection capabilities that are directly relevant to regulated industry deployments. PII detection and redaction automatically identifies and removes personal information (names, Social Security numbers, account numbers, medical record identifiers) from model inputs and outputs, reducing the risk of inadvertent PII propagation through the agent's actions. Grounding checks evaluate whether the agent's response is factually consistent with the retrieved context from Knowledge Bases or provided documents, reducing hallucination risk in regulatory or compliance-sensitive responses. Content filtering blocks prompt injection patterns — attempts by malicious content in the agent's environment to override its instructions — before they reach the model's context window.
AWS AgentCore Identity, integrated with AWS Identity and Access Management (IAM), provides the per-agent credential infrastructure that addresses OWASP LLM06 Excessive Agency's requirement for per-agent identity rather than shared credentials. Each agent deployed in AgentCore Runtime receives a distinct IAM identity — an agent-specific role with a policy that maps to its Cedar Policy-defined tool access permissions. The agent's credential is session-scoped and time-limited, automatically expiring when the session ends.
This eliminates the shared-secret anti-pattern where all agents in an organization share a single service account or API key. With per-agent identity, if a credential is compromised, the blast radius is limited to the specific agent's session and the specific tools that agent was authorized to invoke. The credential cannot be used to impersonate a different agent with different permissions, and the audit trail attributes every action to the specific agent identity rather than to an anonymous shared account.
The AWS audit lake for agent governance combines three service categories: real-time observability, structured event collection, and long-term immutable storage with query capability. Together they provide the compliance record that regulated industries require — a comprehensive, tamper-resistant log of every agent action, decision, tool call, and governance event.
Real-time observability is provided by Amazon CloudWatch and AWS X-Ray. CloudWatch captures structured logs from AgentCore Runtime, including agent session events, tool call attempts, policy evaluation results, and errors. X-Ray provides distributed tracing — for each agent session, X-Ray generates a trace that shows the complete execution path from the initial user request through every tool call, policy check, and model invocation. X-Ray traces are essential for incident reconstruction: when an agent takes an unexpected action, the trace shows exactly the sequence of steps that led to it.
Structured event collection is handled by AWS CloudTrail, which captures API-level events from every AWS service the agent interacts with. If the agent invokes an S3 bucket, a DynamoDB table, or an external API through API Gateway, CloudTrail logs the invocation with the agent's IAM identity, the request parameters, the timestamp, and the source IP. CloudTrail logs are append-only by default and can be configured to write to a dedicated S3 bucket with Object Lock enabled, making them tamper-resistant.
Long-term storage and analysis is provided by S3 (for raw log storage) and AWS Glue (for cataloging and transforming logs for analytical query). The combination of S3 + Glue + Amazon Athena allows compliance teams to query the full history of agent actions using SQL — for example, "Show me all payment operations performed by any agent in the last 30 days where the amount exceeded $1,000" — without requiring custom analytics infrastructure.
The Azure reference architecture for governed agent deployment (covered in the Day 4 post of this series) uses Azure API Management (APIM) as the enforcement gateway, Microsoft Entra Agent ID for per-agent identity, and Azure Monitor with Log Analytics for audit observability. The AWS architecture uses AgentCore Gateway + Cedar Policy for enforcement, IAM + AgentCore Identity for per-agent credentials, and CloudWatch/X-Ray + CloudTrail for observability.
Both architectures solve the same governance problem — every tool call gated, per-agent identity, immutable audit record — using the managed services available in their respective clouds. The enforcement point in Azure (APIM + policy definitions) and AWS (AgentCore Gateway + Cedar) are architecturally equivalent: both intercept every tool call and evaluate it against a policy before allowing or blocking execution. The key difference is the policy language: Azure APIM uses inbound/outbound policy XML; AWS Cedar uses a dedicated, formally verifiable ABAC language. Cedar's formal verification properties — policies can be mathematically proven to be correct before deployment — provide a stronger governance guarantee for regulated industries where policy correctness is a compliance requirement.
Attribute-Based Access Control (ABAC) is an authorization model that evaluates access decisions based on the attributes of the principal (e.g., agent identity, tier, department), the action requested (e.g., read, write, delete), the resource targeted (e.g., payment API, customer database), and the context of the request (e.g., transaction amount, time of day, customer risk score). For agentic AI, ABAC via Cedar Policy allows governance teams to express complex, context-sensitive policies — "agent X may invoke the refund API for amounts up to $500 during business hours for customers with a risk score below 70" — that cannot be expressed in simple role-based access control (RBAC) models.
AWS Step Functions is the managed workflow orchestration service that is commonly used alongside AgentCore Runtime for multi-agent or multi-step orchestration scenarios. For governance purposes, Step Functions provides two important capabilities: execution history and error handling at the workflow level.
Every Step Functions execution generates a complete execution history — a timestamped record of every state transition, every Lambda invocation, every AgentCore agent call, and every branching decision. This execution history is automatically stored in AWS and is queryable via the Step Functions console or API. For regulated industries, Step Functions execution histories provide workflow-level audit records that complement the AgentCore Runtime's agent-level audit records: together, they give a complete picture of how a complex multi-step process executed, which agents were involved at each stage, and what decisions were made at each branch point.
AgentTrust OS is designed to complement AWS's native governance services, not replace them. For organizations building on the AWS Bedrock AgentCore reference architecture, AgentTrust OS adds the governance layer above the infrastructure — classification, certification, and cross-environment audit aggregation.