Most human PAM controls carry over to AI agents. Four breaks: delegation, lifecycle, tempo, and instruction integrity. A test you can run on your own estate.

Key Takeaways

  • Parity is achievable and worth doing. Vaulting, brokering, session recording, and just-in-time (JIT) elevation apply to an AI agent with very little redesign.
  • Parity is also not sufficient. Four properties of agent access change enough in scale and speed that human-era controls no longer hold: delegation depth, spawn-time lifecycle, machine tempo, and instruction integrity.
  • The delegation gap is written into the standard. RFC 8693 records the chain of actors for audit but limits the token consumer to the current actor. Enforcing on the chain has to happen elsewhere, most naturally at issuance.
  • The evidence is moving fast. Regular employee use of AI on corporate devices tripled in one year, from 15% to 45%, and two-thirds of users reach AI services through personal accounts (Verizon DBIR 2026). On the open web, the share of crawler requests made for AI training rose from 22% to 52% (Cloudflare, 2026).
  • Regulators have already named the artefact they want for high-risk AI systems. EU AI Act Article 12 requires those systems to support automatic events logging over their lifetime.

Does human PAM carry over to AI agents?

Yes, and that is the trap. Most of what privileged access management (PAM) does for a human administrator transfer to an AI agent with modest engineering. You can vault the agent's credential, broker its session, scope its entitlement, record what it did, and expire its access on a timer. That work is worth doing, and it is configuration rather than architecture. The trap is treating that transfer as the finish line. Parity gives an agent the controls a human already had. It does not give you control for the four things an agent does that a human never does.

What already transfers cleanly

Start with the honest half of the answer. These controls need configuration work, not new architecture. That last row is where parity starts to fray. Hold it for a moment, because the deeper problem is one row further down: the record of who acted.

Where parity runs out

⦁ Delegation: the chain is recorded, then ignored A human privileged session has one actor. An agent chain has several. A person asks an orchestrating agent to close the quarter. That agent spawns a second agent to read the ledger and a third to write to the reporting database. Four identities, one intent, one write. The standard that governs this case is RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020). It gives you exactly the primitive you would want. An carries "the identity of the acting party," and nested claims express a chain of delegation, with the least recent actor most deeply nested. Then Section 4.1 draws the line that most architecture diagrams miss: "For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the claim. Prior actors identified by any nested claims are informational only and are not to be considered in access control decisions." Read that as an operator. The chain is preserved for audit. It is normatively excluded from enforcement. The resource server that consumes the token sees one actor, whatever depth produced the request. The authorization server performing the exchange is not bound the same way. It can evaluate the full chain before issuing the token at all, which makes issuance the natural place to cap delegation depth or refuse an actor combination. Human PAM rarely had to answer this at depth, because a privileged session usually carried one identity from start to finish. ⦁ Lifecycle: identities born and destroyed inside one task Certification cycles assume the identity is still there when the reviewer arrives. Agent identities are not frequent. The Cloud Security Alliance made this argument plainly in April 2026. Its post, "We Are Fixing the Wrong Problem in Non-Human Identity Security," puts it bluntly: "NHIs are not 'accounts'. They are autonomous trust executors." Identities are spawned on demand. Credentials live for seconds or minutes. Trust is delegated at runtime, not provisioned in advance. If that is true, an inventory is a photograph of a room that has already emptied. The control must move to issuance and expiry, not to the register. Non-human identity (NHI) work that starts with a discovery scan and ends with a spreadsheet will keep finding a different population every time it runs. The US National Institute of Standards and Technology asked the same question in February 2026. Its concept paper on software and AI agent identity puts it directly: should agent identity metadata be ephemeral, or is it fixed? The paper does not answer. That is the useful part. The body working on this has published the open question rather than a settled control. ⦁ Tempo: approvals designed around a human pause A JIT approval workflow works because a person waits. An agent does not wait, and there are a lot of them. Cloudflare reported in July 2026 that more than 50% of traffic on the internet is now non-human. In the same report, crawler requests made for AI training reached 52% as of June 2026, up from 22% in Spring 2025. The Verizon 2026 Data Breach Investigations Report, its 19th edition, records AI bot traffic growing 21% month over month. At that rate, a control that costs a human ten seconds per approval is not a control. It is a queue. The design answer is policy that decides with no human in the path. The human decision moves up a level: which task classes an agent may ever perform, not which call it may make now. ⦁ Instruction integrity: privilege the agent was persuaded to use This failure mode has only a partial human analogue. A human administrator with valid credentials can be socially engineered, but the attack must pass through a person. An agent's instructions are data, and data arrives from the systems it was authorized to read. OWASP catalogues this as LLM06:2025 Excessive Agency. Its framing is precise: "The root cause of Excessive Agency is typically one or more of: excessive functionality; excessive permissions; excessive autonomy." Note what is absent from that list. There is no compromised credential. The agent used exactly the privilege you granted, on an instruction it should not have followed. Sender-constrained tokens help with the adjacent problem. RFC 9449, Demonstrating Proof of Possession (IETF, September 2023) binds a token to a key so a stolen token cannot be replayed. It does nothing about a legitimate token used for an illegitimate purpose. That gap is the one worth budgeting for.

How fast is the non-human side growing?

Two independent measurements, one year apart, pointing the same way. Employee use of unsanctioned AI tripled in one year; crawler requests attributed to AI training more than doubled over a similar window. The same Verizon edition found that 31% of breaches now start with vulnerability exploitation. It reports this as the first time in 19 years that exploitation has been stolen credentials as the biggest point of entry. Third-party involvement rose 60% and now appears in 48% of breaches. Those two findings matter together. Credential theft is no longer the whole story, and the supply chain is where a growing share of the damage travels. Agent identities live at exactly that junction: they are non-human credentials that call third-party services on your behalf.

What auditors will ask for

Regulators moved before the architecture settled, and they picked the log. EU AI Act Article 12, Record-Keeping requires that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." The traceability level must suit the intended purpose. The date that obligation lands on was rescheduled in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, amended Article 113 and moved the high-risk obligations back. Article 12 now applies from 2 December 2027 for systems classed high-risk under Annex III, and from 2 August 2028 for those classed high-risk under Annex I. The original text of Regulation (EU) 2024/1689 set 2 August 2026 and 2 August 2027; a roadmap still built on those two dates is planned against a superseded calendar. Note the phrase "over the lifetime of the system." That is a logging-capability requirement on the system. Articles 19 and 26(6) then require providers and deployers to keep those logs for at least six months. Both apply to an identity population whose individual members may last seconds, so meeting them is a design decision made at issuance, not a reporting decision made at audit. The NIST concept paper frames the same requirement as an open technical problem. It asks how agents can log their actions and intent in a tamper-proof, verifiable way. It asks how to bind an agent’s action back to the human who authorized it. The paper also draws an honest boundary: access for external agents from untrusted sources is excluded from that first effort. A reference architecture for agents you do not control is not coming this cycle. Whether these obligations apply depends first on whether a given system is classed as high-risk. Many agents performing IT operations will not be.

A test you can run against your own estate

Five questions. Each one is answerable from systems you already have, and each has a specific artefact as the answer.
  • Pick one agent write action from last week. Can you name the human it traces to? If the answer requires joining three logs by timestamp, the chain is not being carried, only inferred.
  • How long did the credential for that action exist? If the answer is measured in months, you have a service account wearing an agent's name. Compare against your just-in-time privilege policy for humans, then explain the difference.
  • What happens at approval time when the agent runs at three in the morning? If the workflow waits for a person, the control degrades to whatever the fallback is. Find out what the fallback is.
  • Which tools can that agent call that its task does not require? This is the excessive functionality case from OWASP LLM06, and it is usually an inherited integration, not a decision anyone made.
  • If a regulator asked for the full action log for one agent for one quarter, could you produce it? Including for agents that no longer exist.
An estate that answers all five has moved past parity. An estate that answers the first three has done the PAM work well and has the delegation and evidence work still ahead. Whether your agents are already in production or still in pilot, ARCON recommends that security teams be able to answer five questions. Each is answerable from systems you already have, and each has a specific artefact as the answer.

Where this leaves an identity team

Parity is on the floor. Do it. The alternative is an agent population with no vault, no broker, and no record. Every control that transfers is a control you do not have to invent. Then plan for the part that does not transfer. Carry the delegation chain in your own audit record, and enforce depth limits at issuance, since the token standard will not enforce on the chain at the resource. Move non-human identity governance from inventory to issuance. Set approval at the task-class grain rather than the call grain. Treat tool scope as a permission boundary, because OWASP says that is where the root cause usually sits. Much of this builds on controls you already own. It requires the converged identity view that already tells you which human owns which entitlement, extended so the record does not stop at the first machine. The same argument that makes Zero Trust workable for humans applies here, one hop further down. The next audit cycle will ask for evidence, not architecture. Start with question five.

About ARCON

ARCON builds privileged access, endpoint privilege, identity governance, and cloud entitlement controls for regulated enterprises. Estates covered include on-premises, cloud, and hybrid. This post was drafted with AI assistance and reviewed before publication. Claims here about agent delegation and non-human identity describe published standards and research, not product behaviour. A named subject-matter expert reviews any security capability claim before it is attached to them. Questions about your own environment go to our team via the contact page. Related material is indexed under compliance. Sources
  • Internet Engineering Task Force, "RFC 8693: OAuth 2.0 Token Exchange," 2020. & RFC 8705
  • Internet Engineering Task Force, "RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)," 2023.
  • Verizon, "Verizon 2026 Data Breach Investigations Report," 2026.
  • National Institute of Standards and Technology, National Cybersecurity Center of Excellence, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," concept paper, 2026.
  • OWASP Gen AI Security Project, "LLM06:2025 Excessive Agency," 2025.
  • European Union, "EU Artificial Intelligence Act, Article 12: Record-Keeping," Regulation (EU) 2024/1689, consolidated text as amended, 2026.
  • European Union, "EU Artificial Intelligence Act, Article 113: Entry into Force and Application," Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI), in force 27 July 2026.
  • Cloud Security Alliance, "We Are Fixing the Wrong Problem in Non-Human Identity Security," 2026.
  • Cloudflare, "Content Independence Day, one year on: building the business model for the agentic Internet," 2026.