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 respesented 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 can make that decision point capable of answering harder questions by evaluating the current request together with the agent's recent history.

The broader architecture starts to become much clearer.

Modern IAM is increasingly moving toward stronger workload identity, shorter credential lifetimes, externalized policy decisions, and more context around authorization. 

We are increasingly seeing teams adopt access paths where each workload proves its identity via short-lived credentials or tokens that carry that identity to another system. This identity is carried to an enforcement point where an authorization service evaluates the identity, requested action, resource, current context, and potentially the sequence of events that led there. 

That enforcement point then allows or blocks the action.

Any authentication modernization has to be paired with privilege containment, ownership, lifecycle governance, and continuous exposure monitoring. Otherwise, how do you have enough context about what to authorize?

Modern IAM Authorization Does Not Erase Legacy Credentials

There is a practical problem inside almost every established organization.

Teams are designing new systems around workload identity, OAuth, OIDC, federation, temporary credentials, and richer authorization policies. Years of existing infrastructure still depend on API keys, personal access tokens, service account credentials, certificates, database passwords, and other long-lived secrets.

Those credentials continue to carry standing access. That standing access is part of the organization's existing identity infrastructure. 

Directories and IAM systems may understand the identity and policy, while the credential itself has been copied through repositories, pipelines, tickets, developer machines, or application configurations. GitGuardian found 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% year-over-year increase. Credential leaks associated with AI services grew 81%.

Teams need a map of the standing permissions they already have in order to embrace future-looking authentication via modern workload identity and authorization tech like Dogwood.

GitGuardian Secret Analyzer Shows What a Credential Can Do

Finding a secret answers one important question: where is the credential exposed?

Remediation requires understanding what access sits behind it.

GitGuardian Secret Analyzer enriches supported credentials with information such as roles, permissions, ownership, and related context. This helps teams distinguish between credentials of the same type that carry very different levels of authority.

A narrowly scoped read token presents a different risk from a token with administrative permissions. A valid secret capable of modifying critical resources represents a much larger blast radius. This is where secrets security and IAM authorization meet.

As organizations move toward workload identity and short-lived access, they need to understand the standing privileges attached to the long-lived credentials they plan to remove. Secret Analyzer provides the context for what permissions a secret grants that can help teams prioritize which credentials require immediate attention and understand what access needs to be reduced, recreated, or eliminated during migration.

GitGuardian is also extending privilege context across non-human identities. NHI Governance can surface admin and overprivileged identities across AWS, Microsoft Entra, and Okta, connecting credential exposure to the authority behind the identity. GitGuardian Now Flags Admin and Overprivileged Identities Across AWS, Entra, and Okta

The Exploration Map Reveals Credential Blast Radius

Permissions are only one part of the migration problem; security and IAM teams also need to understand where a credential lives, what consumes it, which resources it reaches, and what might break when it is revoked.

GitGuardian's Exploration Map brings those relationships together.

For a non-human identity, the map can show where secrets are stored in secret managers, which consumers use them, which resources those consumers access, the permissions associated with those resources, and the public or private incidents connected to that identity.

That context becomes especially useful while replacing long-lived credentials.

A team may discover an AWS key in source code and decide that the workload should move to temporary credentials or workload identity. Before revoking the key, responders need to identify every application, job, deployment pipeline, or service that still depends on it.

They also need to understand the permissions currently attached to the credential. Otherwise, the replacement identity can easily recreate years of accumulated privilege.

The Exploration Map gives security, development, and IAM teams a shared picture of that transition.

Secure the Credential Layer While Modernizing Authentication and Authorization

Dogwood is an important step in the evolution of AI agent authorization because it recognizes that identity and point-in-time permissions only tell part of the story. Autonomous systems create sequences of actions, and authorization policy increasingly needs to understand those sequences.

Workload identity, temporary credentials, standardized authorization APIs, and runtime policy are giving organizations better ways to authenticate machines and control what they can do. GitGuardian is helping teams make that transition with visibility into the credential layer they already have.

The GitGuardian platform is focused on detecting secrets across the places developers, workloads, and agents actually use them, wherever they are living in plaintext.

As you adopt workload identity and authorization approaches such as Dogwood, start by understanding the credentials that still carry your existing access. Detect them. Understand what they authorize. Remediate the standing access they represent. Prevent the next generation of workloads and AI agents from rebuilding the same credential sprawl.

Get started with GitGuardian and secure your credential layer as your organization moves toward short-lived workload identity and runtime authorization.