AI Agent Authorization Beyond Authentication: A Look At AWS Dogwood

TL;DR: - Credentials conflate authentication and authorization: Long-lived API keys, tokens, and certificates grant standing access to whoever holds them, making blast radius depend on permissions, not just validity. - AWS Dogwood adds temporal policy for agents: Released in August 2026 and built on Cedar, Dogwood evaluates sequences of prior actions, not just point-in-time requests, to authorize AI agent tool calls. - GitGuardian secures the credential layer underneath: Secret Analyzer adds permission context and the Exploration Map traces consumers and resources, helping teams migrate off long-lived secrets as leaks tied to AI grew 81% in 2025. Most credentials grant standing privilege to the identity holding them Credentials have always sat at the intersection of authentication and authorization. Unfortunately, we have historically combined these two related but separate ideas into single bits of data used by users, workloads, and increasingly, AI agents. Every time someone in the org creates an API key, access token, certificate, or other secret, what they are really generating is an access path. That same credential also carries permissions. If and when the credential is copied into a CI/CD pipeline, application configuration, or local development laptop, that standing access becomes available to anyone who can gain access to it. That model powered modern software for decades. It also created one of the hardest security problems security teams now face. Short-lived, verifiable authentication grants are a move in the right direction The industry has been steadily moving toward workload identity, short-lived credentials, and stronger separation between proving identity and deciding what that identity should be allowed to do. SPIFFE established a practical standard for workload identity, while SPIRE provides a production-ready implementation based on workload and node attestation. SPIFFE itself focuses on identity and authentication, leaving authorization policy to other systems. Cloud-native approaches have been moving in the same direction for years. AWS Security Token Service lets workloads exchange trusted identity for temporary security credentials rather than depending on permanent access keys. AWS itself recommends temporary credentials for workloads to reduce the exposure created by long-lived keys. While many teams focus on authentication, authorization is also on the minds of the identity professionals. The IETF's WIMSE working group is extending the conversation with standards work around workload identity across multi-system environments to explicitly address authorization for workloads while reducing their dependence on long-lived secrets. AI agents make the authorization side of this evolution much more urgent. Agents can authenticate successfully and still make a dangerous decision. It may have a valid identity, use an approved tool, and call a resource it is technically permitted to reach. The harder question is whether that agent should be allowed to take this particular action, at this particular moment, based on everything it has already done. AWS Dogwood is one of the most interesting new efforts aimed directly at that question. Authentication vs. Authorization for Workloads and AI Agents Authentication answers who or what is making a request. Authorization answers what that identity is allowed to do. Static credentials often blur those two concepts. For most IT and SaaS, whoever possesses the key someone generated once, for likely a well-intentioned reason, can exercise those permissions until the key expires, is rotated, or is revoked. That means the blast radius of a leaked secret depends on more than whether the secret is valid. Security teams also need to understand the permissions, roles, resources, and systems behind it. This is becoming a central problem in non-human identity security, as we saw many people discuss at Identiverse 2026. Identity teams now talk about architectures that separate attestation, identity, and authorization. The goal is to move away from long-lived credentials and toward short-lived, attributable access that can be evaluated at runtime. Autonomous agents are forcing us to have this conversation faster than most teams are ready for it. Proving that an agent has a trusted identity only answers the first part of the access decision. Security teams still need to decide what that identity should be able to reach and which actions should be permitted. From RBAC and ABAC to Runtime AI Agent Authorization Authorization is not a new concept, and we have already seen it go through several major evolutions. Role-based access control (RBAC) associates an identity with a role and gives that role permissions. Attribute-based access control (ABAC) adds more context by considering information about the identity, resource, requested action, or environment. Relationship-based systems can evaluate how an identity relates to a resource. Cedar, the AWS open-source access control language, or Open Policy Agent, move those authorization decisions into centrally managed policy that can be evaluated consistently at runtime and represented as code or configuration. Every evolution has added the same thing: more context. But the fundamental question remains: "should this identity be allowed to perform this action on this resource?" Agentic systems introduce one more dimension. And sometimes the answer depends on what happened before. That is where AWS Dogwood comes in. What Is AWS Dogwood? AWS Dogwood was introduced in August 2026 as an open-source governance language for AI agents and their tools. Dogwood builds on Cedar while adding the ability to evaluate sequences of events through temporal policy. Policy engines like Cedar are designed for point-in-time authorization decisions. A policy can evaluate a principal, action, resource, and the context surrounding the current request, then determine whether the request should be permitted. That works well for questions such as whether an agent can read a file, whether a workload can invoke an API, or whether a service can write to a particular resource. Agent workflows create situations where the safety of the current action depends on earlier actions. Imagine a trading platform where someone has deployed an agent to sell shares when certain trends appear. Any individual sale, by itself, may meet normal authorization policy. An organization may also require a human to approve that exact sale within the previous hour. Evaluating only the current request cannot prove that the required sequence occurred. Dogwood adds temporal conditions that let policies examine recent event history alongside the current request. This missing context is why so many rule-based systems struggle with event-based architectures. This central focus of historical action context is what allows their authorization policies to express rules requiring human approval before an action, limits the number of tool calls during a period, maintains a running total across multiple transactions, and restricts later actions after an agent has accessed sensitive information. For autonomous systems, leveraging history for making these decisions at machine speed becomes critical in many situations. Security teams set policy that asks whether an agent should call this tool given everything relevant that has already happened during the session, not just if, in isolation, the request should be allowed. Why AI Agent Authorization Needs Workflow Context Agentic systems can create risk across an entire sequence of individual turns that each appear benign. Reading a sensitive file may be permitted. Making an outbound request may also be permitted. Reading sensitive information and then sending that information to an external system creates a very different security outcome. The ability to do all three is what security researcher Simon Willison calls the "lethal trifecta." AWS designed Dogwood around exactly that sequence and the real-world risks it introduces. Dogwood's temporal conditions can examine prior tool requests and their outcomes. The system can generate an action schema from tools exposed through the Model Context Protocol (MCP), which are the basis for the majority of emerging agent architectures in the enterprise. AI agent security increasingly comes down to the credentials and permissions an agent can reach. Manipulating an agent becomes far more damaging when that agent can access highly privileged credentials or systems. In other words, credentials and permissions determine the real blast radius of agentic AI security incidents. Agents are also frequently operating with credentials originally created for humans, applications, or development workflows. That creates another identity problem because the agent inherits the authority of whoever supplied the credential. Runtime authorization at the tool boundary gives organizations another control point for limiting that authority. How Dogwood Fits With OAuth, AuthZEN, and Modern IAM Dogwood is part of a larger modernization of identity and access management. It fits with the general evolution where OAuth provided a framework for delegated authorization and where OpenID Connect added an identity layer. Technology like SPIFFE and SPIRE increasingly let machines exchange trusted identity for short-lived access without storing permanent shared secrets. AuthZEN adds context pointing towards intent The OpenID Foundation finalized AuthZEN Authorization API 1.0 in January 2026. The specification defines a common interface between a Policy Enforcement Point and a Policy Decision Point. Applications can request an authorization decision without needing to understand the implementation of the policy engine producing it. AuthZEN and Dogwood are largely complementary and are both attempts to broadly answer the question of authorization intent. AuthZEN can standardize how the authorization request reaches the decision point. Dogwood ca