Last November, I started exploring what identity controls should look like for agentic systems.
Other teams were already looking at prompt injection, model safety, and ways AI could strengthen existing security controls. My focus was narrower.
If agents are going to become first-class identities inside an enterprise, what should the identity controls around them look like?
I expected to spend most of my time comparing authentication protocols, OAuth flows, and token exchange patterns. Those things matter, but they were not the hardest part.
The harder questions were about boundaries.
Should an agent have its own identity?
What tools should it be allowed to access?
Can it clone every GitHub repository, or only the repositories required for a task?
Should it be able to search every Google Drive document, or only documents explicitly shared with it?
Can it execute arbitrary bash commands?
Can it reach the public internet, or only approved domains?
How does another service know it can trust the workload making those requests?
The more prototypes I built and the more patterns I researched, the clearer it became that these were not different answers to one identity problem. They were different identity problems happening at different layers of the same system.
This is the mental model I now use when I review agentic architectures.
I am not presenting it as a framework or a new standard. It is simply the model that has helped me separate the controls and ask better questions.
Enterprise AI is about systems, not models
Enterprises are not deploying standalone models. They are deploying agent systems.
The model is the reasoning engine. The harness is everything wrapped around it.
Prompts. Context. Memory. Tools. Workflows. Policies. Approval steps. Observability. Identity.
Most of the engineering happens in that harness. It is where tools are connected, where workflows are orchestrated, where policy is enforced, and where audit records are created.
It is also where most identity decisions are made.
When I started looking at agent security through that lens, the architecture became easier to reason about.
Identity exists at multiple layers
Imagine an agent is asked to review pull requests merged into a production GitHub repository, find the related design documents in Google Drive, query BigQuery for deployment metrics, and save a summary as a Gmail draft.
That sounds like one request.
It is really a chain of identity decisions.
Who initiated the work?
What is the agent allowed to do?
How do downstream services trust the workload making those requests?
Those questions map to three layers.
Layer 1: The originating principal
Every workflow begins somewhere.
Sometimes the origin is a person. Sometimes it is a scheduled job, a business process, a webhook, or an event from a trusted system such as Workday, Freshservice, or GitHub.
The important thing is not whether the initiator is human. The important thing is that the system can always answer:
Who or what started this work?
That context should remain attached to the workflow as it moves through the system.
The originating principal may represent one user, a team, or the organization itself. Whatever the source, it needs a clear identity, an authorization context, and an auditable reason for initiating the work.
Layer 2: Agent identity
Once an agent starts interacting with enterprise systems, it becomes another security principal.
It does not replace the originating principal. It executes work within the boundaries we define for it.
This layer is less about proving that the agent exists and more about controlling what it can do.
Which GitHub repositories can it access?
Which Google Drive folders can it search?
Which BigQuery datasets can it query?
Which bash commands can it execute?
Which internet domains can it reach?
Can it call another agent?
Should a sensitive action require approval?
There are several access patterns here.
In a delegated model, the agent receives scoped authority from the originating principal for a specific task.
In an agent-owned model, the agent has its own identity and resources are shared directly with it. A Google Drive folder, for example, could be shared with the agent account instead of allowing the agent to impersonate each user.
That sandbox can be easier to reason about because the agent only sees what has been explicitly shared with it. The trade-off is that every person using the agent may now have indirect access to the same shared resource. That boundary needs to be intentional.
The agent also becomes another enterprise identity that needs lifecycle management, access reviews, governance, and monitoring.
Neither pattern is correct everywhere. The key is to choose deliberately instead of allowing the access model to emerge accidentally.
This is also where centralized authorization layers become useful. An MCP proxy or gateway can provide one place to enforce which tools an agent may call, apply policy, throttle access, capture attribution, and require approval before sensitive actions.
The same idea applies outside MCP. Bash tools, browser access, APIs, and outbound domains all need explicit boundaries.
Layer 3: Infrastructure identity
The third layer is about trust between workloads.
If an agent running in Kubernetes calls another internal service, how does that service know the request came from the expected workload?
How was the identity issued?
How is it rotated?
How do we avoid long-lived secrets?
How is trust verified again at the next boundary?
This is where workload identity, SPIFFE, SPIRE, mTLS, and short-lived credentials become important.
SPIFFE is not a replacement for mTLS. SPIFFE defines a standard identity for a workload. An implementation such as SPIRE can issue short-lived X.509 SVIDs that are then used with mTLS to authenticate workloads to each other.
The distinction matters. mTLS gives us a secure authenticated channel. SPIFFE gives us a consistent way to say which workload is on the other end of that channel.
The principles I design around
As I worked through these layers, I kept returning to the same identity principles. They are not new AI principles. They are good identity engineering applied to a new class of principal.
Every agent has its own identity
Agents should not impersonate humans.
The originating principal delegates or triggers the work. The agent executes using its own identity.
Keeping those identities separate makes authorization easier to reason about and preserves accountability.
Attribution must survive delegation
Every workflow should answer two questions:
Who initiated this work?
Which agent acted?
Both identities should remain linked throughout the workflow. Downstream systems should be able to see the originating principal and the executing agent.
If either identity disappears, accountability is lost.
Autonomy is earned, not assumed
Least privilege still applies when the workload is intelligent.
Agents should declare what they need. Permissions should be explicitly granted and scoped to the task. Standing access should be the exception.
No ambient credentials. No broad token sitting at rest waiting to be used.
Higher-risk actions should require stronger policy or approval.
Credentials are short-lived and scoped
Credentials should be minted at request time, held in memory where possible, restricted to a narrow audience, and expired quickly.
This limits the damage when a token is exposed through logs, memory, a compromised tool, or an injected instruction.
Long-lived secrets were already a bad pattern. Agentic systems make the blast radius larger and the misuse faster.
Trust is continuously verified
Trust should not be granted once at a gateway and inherited forever.
Identity, authorization, and workload posture should be evaluated again as a request crosses meaningful boundaries.
Every tool call, API request, and workload interaction is another opportunity to verify whether the action is still allowed.
Identity is observable by design
Every action should leave enough evidence to reconstruct what happened.
Who initiated the workflow?
Which agent executed the action?
Which policy version allowed it?
Which tool was called?
Which workload authenticated?
Which credential was presented?
If those questions cannot be answered after an incident, the identity architecture is incomplete.
Closing thoughts
AI identity is not one capability.
It is a collection of controls applied across the originating principal, the agent, and the infrastructure running it.
Each layer answers a different question. Treating them as one problem hides important engineering decisions and usually leads to access models that are difficult to explain or audit.
This mental model will evolve as I keep building in this space. Protocols will improve. MCP authorization will continue to change. Code execution patterns will change. New standards will emerge.
I expect the underlying questions to remain useful:
Who or what initiated the work?
What is the agent allowed to do?
How does the infrastructure establish trust?
Those are now the first questions I ask when I review an agentic system.
How I used AI for this article
I used AI as a technical sounding board and editor while developing this article. The mental model, examples, principles, and conclusions came from my own prototyping, research, and experience working in identity security. I challenged and rewrote the generated text, verified the technical claims, and take responsibility for the final article.