AI agents need guardrails, not trust, for access control
AI agent access control is the practice of binding what autonomous AI systems can see and do to the same fine‑grained permissions and identity checks that govern human users, enforcing those limits through deterministic infrastructure and data governance frameworks rather than trusting model prompts or application logic to behave correctly. Enterprises are learning the hard way that agentic AI changes the risk model: agents don’t just answer questions; they execute tool calls, chain workflows, and quietly move data around. When those actions are uncoupled from identity and policy, every meeting summary, email reader, or CRM assistant becomes a potential data breach in waiting. The key takeaway today is blunt: if your agents can access more than your employees are allowed to see, you don’t have AI innovation—you have an invisible security hole.
AWS’s decision to open‑source Dogwood as a policy language for agent tool calls signals how urgent this has become. Identity leaders describe a governance bottleneck where building agents is far easier than approving them for production, mainly because organisations lack visibility and control over what agents can access and who owns them. Ordinary workers already rely on client‑side agents to attend meetings, read emails, and polish presentations, often without considering that they are feeding sensitive data into models that might later reproduce it for someone else. Against that backdrop, "just trust the agent" is no longer a credible security stance; the only sustainable path is to treat agents as untrusted orchestration layers sitting inside a hardened access‑control perimeter.
Dogwood: From one-off requests to governed tool call sequences
The most important technical shift in AI agent access control is moving from single‑request decisions to sequence‑aware governance of agent tool calls. Cedar, the policy language AWS contributed to an open foundation as a sandbox project in late 2025, evaluates one request at a time and returns the same answer for identical inputs regardless of history. That determinism is excellent for audit and formal reasoning, but dangerously narrow for agents that compose actions into multi‑step workflows. Real‑world constraints live in the sequence: get manager approval before sending a payment, cap the number of external contacts after viewing confidential data, or stay under a running total of downloaded records. Without temporal reasoning, you can fence off each action but not the risky pattern that emerges over time.
Dogwood extends Cedar precisely to close that gap, adding temporal conditions that sit alongside traditional when clauses and can read the agent’s event history. Events correspond to tool call requests and outcomes, including inputs and the requesting principal, and action schemas are generated directly from the agent’s tool manifest. Four operators—formerly, count_within, count_distinct_within, and sum_within—let policy authors express whether something happened recently, how many times, how many distinct values, or what the running total is, while a bind operator lets the current request be compared against these aggregates. Any valid Cedar policy is also a valid Dogwood policy, so teams can layer sequence‑aware rules on top of existing single‑action controls without rewriting. This is agent tool call governance in practice: not smarter prompts, but temporal logic wrapped around every tool the agent can touch.
Bedrock AgentCore: Identity first, agent second
Governance over tool sequences is necessary but not sufficient; enterprises also need to ensure agents never see data the human behind the keyboard isn’t allowed to access. That is why AWS has detailed an approach for propagating user authorization context through AI agents so access control can be enforced by infrastructure and downstream services rather than by the agent itself. In this model, "the agent acts as an orchestrator, not a gatekeeper". The user authenticates with corporate credentials through an identity provider such as Amazon Cognito, and information like their department is added to their authentication tokens and carried through to the services the agent calls. Amazon Bedrock AgentCore Runtime then validates the token and checks authorization before the agent request is even processed, rejecting users who do not meet the configured requirements.
The practical impact is clear in a shared CRM scenario where Sales and Finance employees both query the same AI agent for customer data. Sales staff may need contracts and pipeline details, while Finance needs invoices and payment records. Instead of teaching the agent to remember these distinctions, each downstream system enforces them, refusing to return Finance data to a Sales identity regardless of what the agent asks for. The broader goal is to avoid giving an AI agent broad access and trusting it to filter sensitive information correctly; underlying services should reject unauthorized requests "regardless of what the agent asks for". As AWS engineers put it, "This way, the agent’s credentials are inherently limited to the requesting user’s permissions, and no amount of prompt manipulation can bypass those boundaries". In other words, prompt injection becomes a nuisance, not a breach vector.
Zero trust identity and the missing governance frameworks
Technical controls like Dogwood and AgentCore only matter if enterprises fix their bigger blind spot: identity verification and data governance. Identity leaders describe a governance bottleneck driven by limited visibility into agents created across platforms and devices, plus insufficient control over what those agents can access and who is responsible for them. Organisations are racing to apply agentic technology to boost efficiency and profitability, but "what they’re missing is the governance aspect"—especially investment in identity‑centric programs that treat AI deployment as a security topic, not just an innovation project. Some report that upwards of 90% of AI agents created inside large organisations remain stuck in non‑production status because teams cannot overcome the AI governance hurdle set to prevent harmful behavior. Agents are being built faster than boards can trust them.
This is where zero trust identity is shifting from slogan to practical shield. Zero trust used to mean "Are you who you say you are without relying on a firewall, VPN, or something similar?". In the AI world, it is becoming an authorization mechanism: the core question is whether this identity, at this moment, from this location, can access a particular piece of data, entitlement, or resource. Governance frameworks emerging from regulators and corporate bodies now stress not only understanding what an agent can do, but ensuring end users understand what it should be used for. Once metadata is attached to agents—who owns them, what tools they call, what data they touch—organisations gain the context needed to apply just‑in‑time policy via a central engine. Zero trust and identity controls are no longer bolt‑ons; they are the primary defense against unauthorized agent data access and the difference between safe automation and quiet chaos.
What comes next: From experimental agents to governed ecosystems
The story here is not that access control for AI agents is solved, but that the shape of the solution is finally visible. On the technical side, Dogwood’s roadmap includes absolute‑time windows anchored to wall‑clock boundaries, liveness properties that assert what must eventually happen rather than only what must not, and orchestration policies for multi‑agent systems covering handoffs and locks. These features aim to govern not only single agents but ecosystems where multiple agents coordinate, share tools, and compete for resources. AWS is gathering feedback before accepting contributions and opening up the language as it stabilizes, a sensible move given how quickly agent patterns are evolving. Meanwhile, MCP’s recent specification release makes agent traffic more legible to HTTP infrastructure through required method and tool‑name headers, giving enterprise security teams something concrete to hook policies onto.
On the enterprise side, the next phase is cultural as much as technical. Identity security projects need to become ongoing programs and be treated as central to cybersecurity, with board‑level buy‑in and clarity on identity’s role in AI deployment. Organisations are reassessing which vendors can handle non‑human identities at scale, including agents built across cloud platforms that only recently added agentic capabilities. Some are discovering that their existing identity provider or governance toolset is more relevant to AI than they assumed, especially as connectors appear for major platforms. The direction of travel is clear: AI agents will move out of non‑production purgatory only when they are wrapped in data governance frameworks, sequence‑aware policy languages, and zero trust identity controls. Until then, the most advanced agent is the one that never shipped—and that might be the smartest risk decision many boards have made.
