A Layered Governance Model for AI Agents
In every conversation about agentic security, the starting point is almost always the same: solving the Agent Identity problem. The prevailing argument is that agents must be treated as first-class identities, completely distinct from standard workloads.
While that assumption is theoretically valid, an over-fixation on identity often creates deployment bottlenecks. In this post, we will explore a layered governance approach that prioritizes practical deployment flexibility over idealistic security implementations.
Based on months of hands-on experience grappling with this challenge, it has become clear that relying solely on agent identity assertions—which currently lean heavily on developing IETF drafts and perfect-world scenarios—is impractical for today’s deployment landscape. While new OAuth specifications make their way through standardization, we need a functional approach that marries deployment flexibility with security. Agent identity alone should not gate your solution from becoming usable.
Deconstructing the Agent Identifier
To understand agent identity, it helps to look at a familiar concept: Kubernetes.
A running agent is a process—an instance much like a Kubernetes pod. It is ephemeral and usually one of many. That pod does not carry its own unique name into the world; rather, it runs as a service account, a stable identity that ephemeral pods share and the cluster can verify.
Agent identity works the same way. Each running process is issued a cryptographic credential (such as an SVID or a DPoP key) that proves it belongs to a stable identity. That identity then binds to a Client ID—the exact same concept expressed in the language of an Identity Provider, much like how a service account federates out to a cloud identity.
Ultimately, the agent identifier is a stable, verifiable representation of ephemeral processes, featuring a key pair underneath and an OAuth name on top.
Note: While some argue that every single instance should be permanently associated with an identifier to provide the most granular audit trail, that crosses into a debate regarding session identification, which is distinct from the core identity problem.
The Role of the OAuth Client ID
The OAuth Client ID was devised for one specific job: to tell an authorization server which application is asking.
When a client application wants to reach a Resource Server or API on a user's behalf, it registers itself, receives a Client ID, and uses that ID to be recognized by the authorization server. Paired with a secret, it proves the application is the registration it claims to be.
Bring AI agents into this picture, and you will notice that nothing new needs to be invented for them to acquire an identifier. To an authorization server, an agent is just another client application. It registers, receives a Client ID, authenticates, and requests tokens. Agents act on behalf of human identities—resembling standard app-to-app interactions.
DPoP and SPIFFE: The Cryptographic Evidence
OAuth inherently issues bearer tokens. This means whoever holds the token (or the client secret behind it) can use it. The identifier only proves possession of a string, not that you are the specific instance you claim to be.
DPoP and SPIFFE close this gap by binding the identity to a private key that the instance actually holds:
- DPoP: The client generates a key pair and signs a short proof on every request. The access token is stamped with that key’s thumbprint, rendering a stolen token worthless without the underlying key.
- SPIFFE: The workload is issued a short-lived certificate through attestation and proves possession over mTLS, providing a similar guarantee one layer down in the infrastructure.
In both scenarios, OAuth still names the application and carries the authorization scopes, while the key supplies the cryptographic evidence that turns a replayable bearer token into undeniable proof of the caller's instance.
Decoupling Identity from Authorization
It is crucial to state plainly that identity and authorization are two entirely different problems:
- Identity asks: What is the actor?
- Authorization asks: What may the actor do?
We are accustomed to solving both simultaneously for humans because a human shows up with a strong, singular identity issued by an Identity Provider (IdP). We can take that identity as a given and focus all our energy on policy.
Agents break this habit because their identity is not a given. It arrives at wildly varying strengths depending on the platform hosting the agent, and sometimes it doesn't arrive at all. For example, while platforms like Copilot Studio do a fantastic job of passing agent identifier context, most other platforms currently lack a reliable way to detect this on the wire.
The Three-Rung Governance Model
Once you accept that agent identity requires its own decoupled framework, a natural, three-tiered model emerges, scaling from coarse to fine granularity:
- The Blueprint (Top Rung): This is the definition of an agent—the template onboarded by a builder. It is the logical home for the shared credential (Client ID) and the coarse policies that should apply to every instance of that agent type. It answers the question: "What kind of thing is this?"
- The Agent Resource (Middle Rung): A resource is a running instance—the actual runtime executing in the environment. One blueprint can spawn many resources (like a class creating many objects). Because it physically exists, it is the entity you can attest to and attribute actions toward.
- The Agent Identity (Bottom Rung): This is the cryptographic, per-instance name for a resource. This is the precise fingerprint we are reaching for when we misuse the Client ID. It answers the question: "Which specific one is this?" It is the tier where you apply the most precise governance.
Governing at the Finest Rung You Can Trust
The true payoff of separating identity from authorization—and modeling it via these three rungs—is graceful degradation. Policy attaches to whatever rung the identity assurance supports, ensuring the system degrades safely instead of failing entirely.
- When you have verified per-instance identity: Govern at the Identity rung. You achieve precise least-privilege, clean attribution, and the credential can carry that specific identity downstream.
- When you only have a blueprint: Govern at the Blueprint rung. You lose per-instance precision, but you are not blocked. Every instance of that agent is still covered by a baseline policy.
The Blueprint is your governance floor; the Identity is your precision ceiling. You simply operate at the highest point the cryptographic evidence allows.
If you fuse identity and authorization, an agent with a weak identity either completely escapes governance or forces you to lower security standards for everyone. By separating them, weak identity simply dictates coarser governance, not absent governance.
Conclusion
Building secure, scalable systems in this space demands that agent governance be layered. We must model these tiers, accept that agent identity will reach us at varying cryptographic strengths, and apply governance policies appropriately at all levels. Security should never cease to exist simply because a perfect cryptographic validation is temporarily out of reach.
In every conversation about agentic security, the starting point is almost always the same: solving the Agent Identity problem. The prevailing argument is that agents must be treated as first-class identities, completely distinct from standard workloads.
While that assumption is theoretically valid, an over-fixation on identity often creates deployment bottlenecks. In this post, we will explore a layered governance approach that prioritizes practical deployment flexibility over idealistic security implementations.
Based on months of hands-on experience grappling with this challenge, it has become clear that relying solely on agent identity assertions—which currently lean heavily on developing IETF drafts and perfect-world scenarios—is impractical for today’s deployment landscape. While new OAuth specifications make their way through standardization, we need a functional approach that marries deployment flexibility with security. Agent identity alone should not gate your solution from becoming usable.
Deconstructing the Agent Identifier
To understand agent identity, it helps to look at a familiar concept: Kubernetes.
A running agent is a process—an instance much like a Kubernetes pod. It is ephemeral and usually one of many. That pod does not carry its own unique name into the world; rather, it runs as a service account, a stable identity that ephemeral pods share and the cluster can verify.
Agent identity works the same way. Each running process is issued a cryptographic credential (such as an SVID or a DPoP key) that proves it belongs to a stable identity. That identity then binds to a Client ID—the exact same concept expressed in the language of an Identity Provider, much like how a service account federates out to a cloud identity.
Ultimately, the agent identifier is a stable, verifiable representation of ephemeral processes, featuring a key pair underneath and an OAuth name on top.
Note: While some argue that every single instance should be permanently associated with an identifier to provide the most granular audit trail, that crosses into a debate regarding session identification, which is distinct from the core identity problem.
The Role of the OAuth Client ID
The OAuth Client ID was devised for one specific job: to tell an authorization server which application is asking.
When a client application wants to reach a Resource Server or API on a user's behalf, it registers itself, receives a Client ID, and uses that ID to be recognized by the authorization server. Paired with a secret, it proves the application is the registration it claims to be.
Bring AI agents into this picture, and you will notice that nothing new needs to be invented for them to acquire an identifier. To an authorization server, an agent is just another client application. It registers, receives a Client ID, authenticates, and requests tokens. Agents act on behalf of human identities—resembling standard app-to-app interactions.
DPoP and SPIFFE: The Cryptographic Evidence
OAuth inherently issues bearer tokens. This means whoever holds the token (or the client secret behind it) can use it. The identifier only proves possession of a string, not that you are the specific instance you claim to be.
DPoP and SPIFFE close this gap by binding the identity to a private key that the instance actually holds:
- DPoP: The client generates a key pair and signs a short proof on every request. The access token is stamped with that key’s thumbprint, rendering a stolen token worthless without the underlying key.
- SPIFFE: The workload is issued a short-lived certificate through attestation and proves possession over mTLS, providing a similar guarantee one layer down in the infrastructure.
In both scenarios, OAuth still names the application and carries the authorization scopes, while the key supplies the cryptographic evidence that turns a replayable bearer token into undeniable proof of the caller's instance.
Decoupling Identity from Authorization
It is crucial to state plainly that identity and authorization are two entirely different problems:
- Identity asks: What is the actor?
- Authorization asks: What may the actor do?
We are accustomed to solving both simultaneously for humans because a human shows up with a strong, singular identity issued by an Identity Provider (IdP). We can take that identity as a given and focus all our energy on policy.
Agents break this habit because their identity is not a given. It arrives at wildly varying strengths depending on the platform hosting the agent, and sometimes it doesn't arrive at all. For example, while platforms like Copilot Studio do a fantastic job of passing agent identifier context, most other platforms currently lack a reliable way to detect this on the wire.
The Three-Rung Governance Model
Once you accept that agent identity requires its own decoupled framework, a natural, three-tiered model emerges, scaling from coarse to fine granularity:
- The Blueprint (Top Rung): This is the definition of an agent—the template onboarded by a builder. It is the logical home for the shared credential (Client ID) and the coarse policies that should apply to every instance of that agent type. It answers the question: "What kind of thing is this?"
- The Agent Resource (Middle Rung): A resource is a running instance—the actual runtime executing in the environment. One blueprint can spawn many resources (like a class creating many objects). Because it physically exists, it is the entity you can attest to and attribute actions toward.
- The Agent Identity (Bottom Rung): This is the cryptographic, per-instance name for a resource. This is the precise fingerprint we are reaching for when we misuse the Client ID. It answers the question: "Which specific one is this?" It is the tier where you apply the most precise governance.
Governing at the Finest Rung You Can Trust
The true payoff of separating identity from authorization—and modeling it via these three rungs—is graceful degradation. Policy attaches to whatever rung the identity assurance supports, ensuring the system degrades safely instead of failing entirely.
- When you have verified per-instance identity: Govern at the Identity rung. You achieve precise least-privilege, clean attribution, and the credential can carry that specific identity downstream.
- When you only have a blueprint: Govern at the Blueprint rung. You lose per-instance precision, but you are not blocked. Every instance of that agent is still covered by a baseline policy.
The Blueprint is your governance floor; the Identity is your precision ceiling. You simply operate at the highest point the cryptographic evidence allows.
If you fuse identity and authorization, an agent with a weak identity either completely escapes governance or forces you to lower security standards for everyone. By separating them, weak identity simply dictates coarser governance, not absent governance.
Conclusion
Building secure, scalable systems in this space demands that agent governance be layered. We must model these tiers, accept that agent identity will reach us at varying cryptographic strengths, and apply governance policies appropriately at all levels. Security should never cease to exist simply because a perfect cryptographic validation is temporarily out of reach.