Five-layer blueprint — IAM scope, Guardrails, Action Groups, CloudTrail — that passes a financial-services security review
AWS Bedrock AgentCore handles compute and orchestration. It does not handle the governance layer. Here is the five-layer reference architecture — IAM scoping, Guardrails, Action Group contracts, runtime policy, and CloudTrail — that passes a financial-services cloud security review.
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.
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.
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 directly relevant to regulated industry deployments: PII detection and redaction automatically identifies and removes personal information from model inputs and outputs; grounding checks evaluate whether the agent's response is factually consistent with the retrieved context from Knowledge Bases; and content filtering blocks prompt injection patterns 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 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 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.
Structured event collection is handled by AWS CloudTrail, which captures API-level events from every AWS service the agent interacts with. 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 with Amazon Athena).
The Azure reference architecture for governed agent deployment 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 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.
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.
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.
AgentTrust OS integrates natively with AWS Bedrock AgentCore — adding governance classification, certification, and board-ready reporting above AWS's native infrastructure.
Start Free →