Agents need their own first-class identities because they act across many systems on behalf of users and combine machine-like access with human-like behavior.
2
Existing authorization models struggle with agents because their permissions must be narrow enough to limit damage while remaining flexible enough for nondeterministic work.
3
Middleware can create a trust boundary around agents, enforce dynamic access rules, and provide the logging and observability needed for production use.
Summary
Michael Grinich argues that agents need first-class identity support in enterprise software. An agent may act for a user across Jira, Salesforce, Slack, email, and other systems, while also accessing data associated with multiple users. That makes ordinary user impersonation and machine-to-machine authentication insufficient. The hard problems include headless sign-in, long-lived sessions, credential storage, dynamic least-privilege permissions, audit trails, and visibility into fast-moving agent activity. Grinich describes four architecture patterns: persona shadowing, delegation chains, capability tokens, and escalation to humans. He also surveys emerging standards around OAuth, OpenID Connect, User-Managed Access, GNAP, OIDC for Agents, and verifiable credentials. His practical recommendation is to place managed middleware between agent code and enterprise systems, since prompt injection and hijacking mean the agent itself cannot be fully trusted. He expects agent-driven activity to become a much larger share of software usage.
Agents need identities that combine machine access with user accountability
Grinich says an agent is different from a bot, an integration, or a normal machine-to-machine service. Agents behave more like people inside systems, but they need broad access across many tools and may act on behalf of users. One agent might need to read data from multiple users in a single workflow. That creates a hybrid identity problem. Certificate-based machine authentication does not capture the user context and delegated behavior involved. Grinich argues that agents need native machine identity support while remaining tied to the people they represent. This connection matters when an organization needs to know who authorized an action or who is responsible for it.
Headless sign-in and long-lived sessions create new credential problems
Agents need to log in without typing into a browser, but they may also need to operate a front-end application in a computer-use workflow. Grinich describes a tension between persistent access and ordinary user sessions that expire or sign out. Teams must decide where agent credentials live, how those credentials are refreshed, and how they are stored securely. The session itself may be long-lived even though its tokens should not last forever. He points to browser-based systems as an example of the open storage and security questions. Authentication for agents therefore includes the full lifecycle of credentials, rather than only the initial login.
Least privilege has to adapt to nondeterministic agent behavior
Grinich describes a difficult authorization tradeoff. An agent should have a narrow ability, such as sending a particular email or reading a limited amount of data. At the same time, its value often depends on access to a broad environment, including code, bugs, customer conversations, and several business systems. Since the agent may decide what it needs while running, fixed permissions do not always fit. Grinich says permissions need to be dynamic. The system must constrain what the agent can actually do while leaving enough room for tasks that could not be listed in advance. This is why existing least-privilege models do not directly carry over.
Auditability must connect every agent action to a person
The production database example is also a compliance problem. Organizations need a record of who or what performed each action, and agents need to be tied to a person at the end of the process. Grinich asks how review requirements should work when agents review code or perform other work that normally requires human oversight. Speed makes the problem larger. Agents can perform many actions rapidly, spawn other agents, and create activity that is difficult to inspect manually. Enterprise logging systems therefore need to capture agent activity and make it observable. Without that record, teams cannot investigate harmful actions or satisfy requirements such as SOC 2 controls.
Persona shadowing limits an agent while preserving the originating user
Persona shadowing gives an agent a secondary identity that reflects a user but has only a subset of that user's privileges. Grinich compares this with a human identity such as Michael and separate identities such as agent one Michael and agent two Michael. The shadow persona can have stricter access limits than the user, which creates isolation and accountability. Each action remains linked to the original human identity. Pure impersonation would mirror the user's full authority and could give the agent too much power. Shadow personas also allow teams to create role templates for recurring agent access patterns. Grinich says this is the closest pattern he has seen to agent identity in current use.
Delegation chains and capability tokens express narrower forms of authority
Delegation chains pass a verifiable token from one system to another, with each link carrying forward the original user's authorization. This lets an agent's authority persist across a sequence of calls while preserving the delegation context. Capability tokens take a more specific approach. Grinich gives the example of a token that lets an agent read Bob's calendar for the next 60 minutes. Such a token can be self-contained, time-limited, and restricted to one action or API call. Possession of the token proves authorization for that action. He compares the idea with Google's macaroons work and distinguishes capabilities from broad roles or permissions.
Human approval can become a weak control through consent fatigue
Escalating every sensitive action to a person is easy to understand, but Grinich does not treat it as a complete security model. If users see repeated prompts to approve actions, they may approve them without checking. He compares this to installation prompts on a Mac or Windows laptop, where people eventually accept broad scopes. Human approval may satisfy some compliance expectations, yet it can fail as a practical access control when the person is approving too many requests. Grinich expects applications to combine human escalation with shadow identities, delegation chains, or capability tokens. The right combination depends on the application, its access patterns, and the customer's restrictions.
Middleware gives untrusted agents a managed boundary around enterprise systems
Grinich says teams cannot assume that an agent will follow a narrowly defined plan. Evals and guardrails do not prevent prompt injection or prompt hijacking, so the agent should be treated as untrusted. His recommended pattern is to place middleware between agent code and enterprise resources. That layer can apply dynamic rules, log activity, and enforce access decisions outside the agent's own code. He describes WorkOS products including AuthKit for identity and MCP, FGA for granular authorization, and systems for detecting fraud, bots, and abuse. He also mentions Microsoft's workload identities and Cloudflare's work on MCP authentication as related examples.
Software activity may shift from mostly human-driven to mostly agent-driven
Grinich predicts that the balance of software activity will change substantially. He says most application traffic today comes from people logging in and using products, with a smaller share coming from APIs or scripts. He expects that relationship to reverse for some products, with agents becoming the main way users interact with software. In the question period, he compares this to ghost kitchens, where a business may exist mainly for delivery rather than in-person visits. He cites Perplexity's hotel-booking feature and a company that provides an API without a normal user interface as examples of this direction already appearing. The shift makes agent identity a product requirement rather than a specialist concern.
"We really need to do this. AI is clearly taking over the world."03:16
Who should watch
You are building an enterprise agent that needs to act across SaaS products and want a model for identity, delegation, and scoped permissions.
Your agent can access sensitive systems, but you do not yet have a clear way to tie actions to users or send activity into enterprise logging.
You are deciding whether to put authorization and policy enforcement in application code or in a separate middleware layer.
