Why AI agents break traditional identity models
The software industry is shifting from evaluating developers on their ability to write code to evaluating them on their ability to orchestrate AI agents. Sahil Agarwal, an area engineering leader who leads the identity and authorization stack at a major cloud collaboration platform, describes this as a move from can you write a good line of code to can you work with agentic systems well. The problem is that teams racing toward capability are forgetting that identity, accountability, and trust are the risky bits. Agents have moved from passive chat interfaces into production systems where they take real-world actions with real-world consequences, and the identity models built for humans over decades do not transfer cleanly to autonomous delegated actors.
The traditional model was straightforward. Humans had access to apps, apps had access to resources, and permissions flowed through hierarchical decisions. A manager granted access, a team membership determined scope, and a human was always in the loop. The intent was always known. Agents break this model because they are not acting in a vetted, human-in-the-loop fashion. They can think about situations, act autonomously, make decisions, and chain calls to other tools within an ecosystem. As frontier models improve, the autonomy and intent of the agent itself changes as well, which means the old access control patterns cannot be applied one-to-one.
The DPACT framework for bounded delegation
Agarwal developed a framework called DPACT, which stands for Delegation, Policy, Auditability, Context, and Time. The framework emerged from his own experience building agents and noticing a pattern: every time he tried to build something, he was accidentally giving too much access to the agent than it required. The pattern repeated across the GitHub repos and self-serving agent projects he tested. The framework is designed to score how well an agentic system handles these five dimensions.
Delegation means the system can clearly state on whose behalf the agent is acting. Policy defines what the agent can do and, critically, what it cannot do. Auditability ensures that thirty days later, you can look at logs and explain why an agent took a specific action. Context captures the circumstances under which the agent operated. Time defines when the agent's authority ends. Each dimension addresses a specific failure mode that shows up in production agentic systems, and together they form a blueprint for building agents that operate within defined, secure boundaries rather than having unlimited access to systems and data.
On behalf of versus impersonation
The most important principle in the framework is that agents should always act on behalf of a human user and should never impersonate that user. If an army of agents is working in production, each should be a delegated autonomous actor with its own identity, not a copy of the human it serves. Agarwal points to an early version of a tool he calls OpenClaw as a case study in what happens when this distinction is ignored. The first rendition let agents represent and act as the user rather than on behalf of the user, creating a security nightmare. Agents accumulated information they were not supposed to have and fell into the trap of overprivileged access.
The practical difference matters. A correctly designed agent should work like a contractor who says I am representing Sahil and I want to do this for him, not like someone who opens a bank account pretending to be Sahil. The distinction sounds subtle but it determines whether an agent can escalate privileges, access data outside its scope, or chain actions in ways the human never intended. Over-privileged agents are dangerous because they can do anything you ask. Over-restricted agents are worthless because they constantly nag humans for permissions. The goal is bounded authority: enough access to complete the task, revoked when the task is done.
What this means for teams building agentic systems
The most effective approach to securing production agentic systems is incremental governance. Start with an inventory of what agents exist and what they can access. Add visibility into what they are actually doing. Move toward bounded task grants as a first-class feature rather than relying on long-lived API keys that grant permanent access. This progression avoids stifling innovation while establishing the guardrails needed to operate safely.
For developers building agents, the practical takeaway is that identity and authorization need to be designed first, before you know what the agent is capable of. Design delegation first. Have the right scopes and grants and policies in place so that before you wield the agent and before you know its power, you already know how to use it appropriately and responsibly. The agents that will succeed in production are the ones that can explain who they are acting for, what they are allowed to do, and when their authority expires. Anything else is a bet that the agent will never do something you did not intend, and that is a bet that does not pay off in production.