AI Agent Permission Inheritance From Human Principals

AI agent permission inheritance exposes a flaw in access models built for people. Those models give people broad authority and rely on their judgment to limit how they use it. Agents inherit authority without the human restraint that limits its use. Each agent’s execution must be governed against the user’s entitlement, the agent’s own permissions, and the specific task, rather than treating a valid human credential as permission to proceed.

Why human permission models were never designed for agents

Traditional identity and access management, or IAM, concentrates on the moment access begins. A person presents credentials, the system checks them, and access is granted or denied. That establishes who may enter, but not whether every subsequent action serves the task that brought them there. The distinction is easy to miss with people. An employee with broad access generally uses only the small part needed for the work at hand.

Role-based and attribute-based access controls were calibrated around that self-limiting behavior. They define the reach available to an identity, while the person holding it supplies a further, informal restriction. Someone may be able to open a file without having any reason to open it. Human judgment quietly closes the distance between those two conditions.

An agent operating on that person’s behalf does not preserve the distinction merely by receiving the same credentials. It acts on instructions with the authority available across the applications that identity can reach, rather than asking what the human would ordinarily have done. Broad grants always depended partly on behavior outside the access model. Agents make that latent dependency impossible to ignore.

What agents actually inherit when they pick up a human credential

In the investigation, the token’s scope string was “user_impersonation”, granting the agent full user rights. Those rights included two permissions on one store and 107 on another, including delete rights on a secure database. The agent had not received a purpose-built mandate. It had received the user’s reach, with all the unevenness that an accumulated permission set can contain.

Logs captured credential, machine, and tool IDs, but not agent intent. They could identify the credential involved without explaining the purpose behind its use. That distinction becomes consequential when software exercises access accumulated through years of role changes. A familiar identity in a log is not evidence of a familiar decision.

Agents can authenticate once with a long-lived token or API credential, then operate across sessions, systems, and contexts without an intervening governance checkpoint. Stale delegations and over-scoped credentials become active attack surfaces when an agent uses them. This is the “identity dark matter” that human workflows had left largely undisturbed.

An employee may be entitled to open thousands of files but consult only those relevant to a task. An agent inheriting that access can scan everything it can reach, surfacing HR files, executive communications, and client data without intending to seek them out. One invocation can therefore cross several unrelated systems. The inherited permission permits the traversal, even though no human explicitly authorized that agent to visit those resources.

How self-limiting behavior was doing the work that governance never did

Overprivilege survived because much of it stayed dormant. Humans supplied a practical brake by declining to exercise most of their available access. Removing that brake exposes a weakness in the model’s assumptions. OWASP’s GenAI Security Project recognized the resulting risk as LLM03, Excessive Agency, in the OWASP Top 10 for LLM Applications 2026, v1.0, August 2026. The classification names what broad permissions become when an autonomous actor can put them to work.

Research on user-authored permission policies complicates the obvious response of putting a person back into the loop. The study compared per-action human approval, automated model review, and standing user-authored rules across 113 participants. User-authored rules blocked meaningfully less overreach than per-action approval. Yet people had approved most of the overreach that took place.

Participants overwhelmingly chose “ask” for most rules. That preserved their ability to decide case by case, but prevented the standing policy from settling those decisions in advance. The preference was understandable. A person can want control without being ready to encode every future judgment as a durable rule. For machine-speed execution, however, that leaves the system dependent on decisions whose consistency the study itself calls into question.

The inbox deletion involving Meta’s Director of Alignment illustrates a related distinction. An instruction to an open-source agent to “confirm before acting” failed to prevent deletion of real inbox messages. A natural-language request was not an enforced boundary. Together, the research and the incident undermine both easy answers, namely that advance rules can capture all relevant judgment or that runtime approval can reliably supply it. Neither is enough on its own at the speed agents work.

Where the risk compounds: multi-agent delegation chains

Agents query one another to break larger goals into subtasks, giving downstream agents authority to complete narrower pieces of work. If every specialist receives the user’s global privilege set, the permissions do not narrow with the task. A local failure can then expose the wider service ecosystem. The boxes on the organizational chart get smaller, but everyone keeps the master key.

Credential handling can also break the chain of trust. Many deployments give agents new credentials at each hop instead of keeping the original delegation, so downstream agents end up with permissions the original user never approved. Unit 42’s October 2025 Agent Session Smuggling research illustrated a related danger through a sub-agent response that embedded a silent stock trade of 10 shares. The consequential action traveled inside an otherwise routine delegation response, invisible to the governance layers above it.

OpenClaw’s CVE-2026-33579 shows a control-plane version of the problem. Errors in scope propagation let a caller who had pairing privileges but lacked admin privileges approve device requests for admin access. The failure was in how authority moved. A system can lose its intended boundary this way before downstream agents even start work.

Speculative design research on agent inheritance protocols from August 2026 extends this logic to “feral” agents on decentralized infrastructure. It describes agents that keep executing after a principal dies, loses access, or belongs to a DAO that dissolves. This is the logical endpoint of delegation without durable ownership or revocation, in which the substrate outlasts the principal.

Industry architecture is beginning to recognize delegation as its own problem. Google’s Agent-to-Agent protocol, contributed to the Linux Foundation in 2025, provides a horizontal layer for agent collaboration that complements MCP’s vertical layer for tool interaction. That distinction gives collaboration an explicit architectural place. It does not, by itself, establish that every handoff is authorized.

What breaks down when an agent acts and no one can prove it was authorized

An agent can enter an organization’s systems without entering its identity governance process. Rather than going through an access request and onboarding into identity governance and administration, or IGA, it inherits credentials from an existing identity and begins executing. The resulting actor has no provisioning record of its own. When delegation is also unrecorded, an audit cannot reconstruct the chain from the original authorization to the final action.

The missing evidence also matters outside security operations. Agents can access systems and bind humans to transactions, placing their conduct within agency, tort, contract, and computer access law. An organization cannot assume that uncertainty about the software’s decision removes responsibility for what the software did.

California’s AB 316, effective January 1, 2026, prohibits defendants who “developed, modified, or used” an AI system from asserting that the AI autonomously caused the harm. That rule limits the autonomy defense rather than supplying a technical authorization mechanism. It makes the accountability gap harder to treat as an internal documentation problem. “The agent did it” is not the escape route it might appear to be.

Singapore’s Model AI Governance Framework for Agentic AI, launched January 22, 2026, likewise establishes that organizations remain legally accountable for their agents’ behaviors even though compliance with the framework is voluntary. An organization may choose how to adopt a framework while still having to answer for an agent’s conduct. The absence of a recorded mandate leaves that answer harder to substantiate.

Why the regulatory and standards response has not yet closed the gap

NIST published the Accelerating the Adoption of Software and AI Agent Identity and Authorization concept paper in February 2026. It identifies the central mismatch directly, noting that enterprise identity infrastructure was designed for human users and conventional software services, while AI agents fit neither category. The NCCoE’s four focus areas are identification, authorization, access delegation, and logging. Those are the right subjects for the problem described here. They are not yet an enforceable solution.

The concept paper requested comment. Its comment period closed April 2, 2026, and NIST received more than 600 responses. As of publication, NIST has issued no binding AI agent authorization standard, and the February draft gives auditors no specific control to test.

OWASP’s excessive agency classification has a similar limit on what it does. It names a risk category without specifying enforcement mechanisms or monitoring requirements. The legal frameworks described above establish responsibility after harm, but do not supply the missing pre-deployment controls. A named risk remains a risk until a system can constrain it.

Meanwhile, line-of-business teams use low-code platforms and vendor-supplied integrations to deploy agents, often with no security review during provisioning. This route can bypass the workflows through which security teams would normally learn that a new actor exists. The delay is structural. Work on standards may make it clearer how to govern agents, while teams keep deploying them outside the processes meant to put that governance into practice.

What a permission model built for agent execution actually requires

The operational response is to calculate authority for each invocation. Effective access should be the intersection of what the user is entitled to, what the agent is permitted to do, and what the specific task requires. Each input limits the others. A user’s entitlement to delete a database does not authorize an agent performing an unrelated task to do so.

The AWS Cedar reference implementation shows that this architecture is buildable. It controls execution and delegation through a maximum delegation depth of five hops, per-invocation task-subset scoping, and trust scores for agent-to-tool calls. The chain need not become a privilege escalator.

Enforcement must also operate inside the session. That requires discovering agents, monitoring approved AI traffic in real time, detecting anomalous behavior and policy violations, and constraining actions before a violation completes. Complete audit logs must connect each action to the person or policy that authorized it and the limits that applied. Logging afterward is necessary but insufficient.

Finally, an agent needs an identity that can be governed independently of its human principal. Dedicated service principals, enriched logs that capture agent intent, and scoped, revocable mandates allow its authority to be withdrawn without disrupting the human’s own access. Discovery must include line-of-business deployments that bypass identity lifecycle workflows. Otherwise, the organization cannot revoke what it does not know exists. Access models built for humans were not wrong, but for autonomous execution they were built for the wrong actor.