Agent Identity Patterns: Which One to Use, and When
The real choice is not whether an agent has credentials. It is which identity pattern fits the ownership boundary around the action.
Framework at a glance
How to read the model and what each layer is doing.
The real choice is not whether an agent has credentials. It is which identity pattern fits the ownership boundary around the action.
Runtime identity is my default for platform-owned actions and background work.
Delegated access belongs only where the data or action is user-owned.
Hybrid patterns are usually the right enterprise answer when one workflow crosses both boundaries.
Most teams talk about agent identity as if it were a credential problem. I think it is a pattern-choice problem. The real question is not whether an agent has access. It is what kind of access fits the ownership boundary around the action.
I use a simple rule. If the action belongs to the platform, the runtime should carry its own machine identity. If the action belongs to a person, the agent should use delegated access. If one workflow crosses both boundaries, I keep the two patterns separate instead of collapsing them into one credential.
framework
The decision rule I use
Pick the identity pattern by the ownership boundary around the action, not by what is easiest to wire up in the demo.
- Runtime identity for platform-owned work
- Delegated access for user-owned systems
- Hybrid when one workflow crosses both
The four patterns I see in practice
I keep coming back to the same four patterns. Three are useful in the right context. One is a shortcut that usually creates trouble later.
| Pattern | Best for | Why it works | Where it breaks | My take |
|---|---|---|---|---|
| Runtime identity | Platform-owned actions, tool execution, background jobs | Clear machine principal, least privilege, strong audit trail | Does not solve user-owned access on its own | My default for platform work |
| Delegated access | User-owned files, mailboxes, repos, calendars | Respects the user's existing permissions and consent | Bad fit for broad platform actions or shared automation | Use only where access belongs to a person |
| Hybrid pattern | Workflows that cross platform actions and user-owned systems | Keeps machine identity and user delegation separate | Takes more design work up front | Best enterprise pattern in serious agent systems |
| Shared keys | Fast demos and shortcuts | Easy to wire up once | Weak audit, weak revocation, no real boundary | Avoid in production |
The choice gets simpler when you ask who actually owns the action.
A simpler way to decide
I do not start with vendor features. I start by asking what the agent is touching and who owns the action that follows. That is what tells me which identity pattern belongs in the design.
How I choose the pattern
Ask what the agent is touching
Is the agent acting on platform-owned tools and systems, or stepping into data and actions that belong to a user?
Find the ownership boundary
The ownership boundary is the real design signal. Platform work and user-owned access should not be treated as the same thing.
Choose the identity pattern
Runtime identity covers platform work. Delegated access covers user-owned access. Hybrid patterns keep both cleanly separated in one workflow.
Put policy and audit in the middle
Whichever pattern you choose, approvals, scopes, and audit trails belong between identity and action.
Which one I use, and why
Runtime identity for platform work
If the agent is running background jobs, calling internal tools, or taking platform-owned actions, I want the runtime to have its own machine identity. That gives me a non-human principal, scoped permissions, cleaner audit trails, and a straightforward revocation path.
Delegated access for user-owned systems
If the agent needs a user's files, mailbox, calendar, or repository access, I want delegated access instead. The action should stay inside the user's existing permission envelope. That keeps consent, scope, and revocation aligned with the person who actually owns that data.
Hybrid when one workflow crosses both
The enterprise reality is that many useful workflows cross both boundaries. A runtime might need its own machine identity for platform work, then step into delegated access for one user-owned action. That is why I see the hybrid pattern as the real production default for serious agent systems.
Why the hybrid pattern is usually the real enterprise answer
Why I trust it
- Keeps platform actions on a machine identity
- Preserves user consent where access is user-owned
- Makes audit trails easier to explain and defend
What it asks of the team
- Takes more design work up front
- Forces the team to model ownership boundaries explicitly
- Feels slower than one shared credential in early prototypes
Shared keys only for throwaway demos
I still see teams reach for one shared API key because it is fast. It is fast. It is also the wrong mental model for production. Shared keys flatten identity, make audit trails fuzzy, and turn revocation into a mess. If a workflow matters enough to keep, it matters enough to give the agent the right identity pattern.
If an agent can take action, it needs an identity of its own. If it touches user-owned systems, it also needs a boundary.
My default framework
takeaway
Which pattern to use
Most teams do not need a new identity theory. They need one practical default and one explicit exception.
- Start with runtime identity for platform-owned work
- Add delegated access only where the workflow crosses into user-owned systems
- If one shared key still looks easiest, you are probably optimizing for demo speed over operational trust
That is the framework I use. It is simple enough to teach, practical enough to implement, and strict enough to keep agent systems governable once they leave the demo and start touching real enterprise systems.
Discussion
Responses, reactions, and open questions.
The article stays static. The conversation sits underneath it. Sign in with your email, react to the argument, and join the discussion.
Join the discussion
Use your email to get a one-time sign-in code. First comments may wait in moderation before they appear publicly.
Continue reading