Identity & credentials for non-human actors

What an agent is allowed to be, and what it is allowed to hold.

18documents on this topic
14organizations represented
3issues named
11sourced citations
0sourced statistics

The state of it

One of 6 topics within Security & threat model.

An agent is not a user and it is not a service. It acts on behalf of somebody, it holds credentials of its own, it can be one of thousands of identical instances, and it may delegate onward to another agent that the original human never heard of.

Existing identity systems were built for two cases: a person who logs in, and a service that runs. The agent is a third case, and the gap shows up in ordinary questions that have no clean answer - on whose authority did this act, which of the 2,000 instances did it, what was it allowed to do at that moment, and can it be revoked without taking down the other 1,999.

The standards-side material here is unusually concrete: identity for agents as a first-class class, credentials held in agent-side secure storage, discovery and trust establishment between agents, and - the part that matters most operationally - immediate revocation propagated to every session, so that a compromised or misbehaving agent stops being able to act everywhere at once.

That last capability is the difference between having an incident and having an outage you chose.

The issues, by agreement

How many independent organizations name each issue as a problem. An issue is only as real as the number of separate publishers that identify it, so the count is the ranking. Bars are organizations, not documents. Where the count reads ours, no publisher here states the issue and the analysis is our own.

names it as a problemdisputes itqualifies it
Agents run on one-time authentication and inherited permissions that cross boundaries
3
There is no way to revoke an agent everywhere, immediately
2
Nobody can say whose authority an agent acted under
1

Who takes which position

The chart above counts positions; this shows whose they are. Read down a column for what one organization holds across the whole topic, and across a row for who lines up on one issue. Where a cell carries more than one position, the strongest is shown and the rest are in the tooltip.

Ddisputes it Qqualifies it Nnames it as a problem Pproposes a fix
Identity & credentials for non-human actors: 3 issues against the 5 organizations cited on them. The number under each name is how many of these issues it is cited on.
Issue Cloud Security Alliance · 3 CISA · 2 Palo Alto Networks · 2 AWS · 1 IBM · 1
Agents run on one-time authentication and inherited permissions that cross boundaries P N N P N
There is no way to revoke an agent everywhere, immediately N · N · ·
Nobody can say whose authority an agent acted under P N · · ·

A dot means this organization is not cited on that issue. It does not mean they are silent on it: an organization is cited where its document takes a position we could locate, and the absence of a citation is the absence of a finding, not a finding of absence. Who is represented lists everyone working on this topic, including those not cited above.

Where they disagree

No contradictions recorded on this topic yet.

The issues in full

Each issue carries the organizations that name it, the numbers behind it, and the remedies proposed - with the concrete steps under each. Every citation points at a section of a named document, so any count here can be checked.

Issue 013 organizations name it2026 evidence

Agents run on one-time authentication and inherited permissions that cross boundaries

An agent is stood up with a credential borrowed from whoever built it, authenticated once, and carries permissions across organizational boundaries that no one would grant a new employee on their first day.

This is the mechanism behind most of the identity findings elsewhere in this theme, stated plainly: authentication happens at the start and authorisation is inherited rather than checked per action. The consequence is that the agent accumulates reach it was never assessed for, and that reach is invisible because no single system sees the whole of it. The direction the material converges on is narrower: each thing an agent does should be traceable to the person it serves, the purpose it was asked for, and a route that granted it - checked at the moment of the act, not at start-up.

How to fix it — 1 approach, 3 steps

Authorise each action, do not inherit a session

Stop granting agents standing permission at start-up. Check authority per action against the person and purpose it is acting for.

Done when No live agent runs on a credential belonging to a person, and for anything touching customer data the log shows an authorisation check against each action rather than one at start-up.

  1. Find which live agents run on a credential borrowed from a person, and whose.0-30 daysHead of identity
  2. Issue each agent its own identity, scoped narrower than the person who built it.30-90 daysHead of identity
  3. Move authorisation from start-up to per action, beginning with anything touching customer data.90-180 daysHead of security engineering
The evidence — 6 documents
OrganizationDocumentPosition
CISAOther · April 2026Careful adoption of agentic AI servicesOur reading Names the timing error underneath the inherited credential: entitlements get granted broadly to reduce friction and are assessed at deployment, which is the point at which least is known about what the agent will actually do. What follows is scope creep, and it travels - where one agent trusts another, compromising the trusted one reaches everything downstream of it. Six national cyber agencies put their name to this jointly, which makes it the closest thing in this theme to a settled position rather than one publisher's view.Permissions checked once, at the moment of least informationnames it
IBMHyperscalerSecuring enterprise AI at scaleOur reading Reports agents enabled through one-time authentication and inherited permissions crossing organizational boundaries, and 45% of executives conceding shortcomings in access controls and identity protections, from a survey of 1,000 C-level executives.One-time authentication and inherited permissionsnames it
Palo Alto NetworksVendorUnit 42 2026 Global Incident Response ReportOur reading Names it from frontline casework rather than as a caveat: identity weakness is implicated in almost 90% of investigations, and over-scoped roles, inherited permissions and unretired grants are described as repeatable routes to higher privilege - with agent accounts deployed on broad defaults and long-lived credentials among the non-human identities carrying them.Where this ends upnames it
AWSHyperscaler · April 2025Navigating the security landscape of generative AIOur reading Adds the part usually left out of an access review: an over-permissioned agent does not only reach too far at the moment it runs, it deposits what it reached into logs and caches that outlive it. Asks for role-based limits on the agent, logs written so they do not capture the sensitive content themselves, and cached data encrypted and expired on a stated schedule.The copies the permission leaves behindproposes a fix
Cloud Security AllianceInstitutionAgentic AI Identity and Access ManagementOur reading Proposes the identity machinery that makes per-action checks possible rather than a session granted once and trusted thereafter.Per-action authorisation for agentsproposes a fix
IBMHyperscalerSecuring enterprise AI at scaleOur reading Proposes that an agent action carry the person it serves, the reason it was asked for and the grant that permitted it, and that agents be stopped from carrying permissions forward between sessions. Published with a security vendor, whose interest runs the same way as the recommendation.Tie each act to a person, a purpose and a grantproposes a fix

Issue 022 organizations name it2026 evidence

There is no way to revoke an agent everywhere, immediately

Credentials can be rotated and accounts disabled, eventually and per system. There is no single action that stops a given agent acting across every session and every integration at once.

Revocation is the control that makes every other control recoverable. Without it, the response to a misbehaving agent is a sequence of per-system logins while the agent continues to act, which is precisely the window in which the frontline data says exfiltration now happens fastest. The published designs describe what working revocation requires: a resolvable identity for the agent, a state store that every enforcement point consults, and termination that propagates rather than being applied system by system.

How to fix it — 1 approach, 3 steps

Build one action that stops an agent everywhere

Make it possible to revoke a named agent in a single action that propagates to every session, integration and downstream delegation.

Done when A revocation test on a live agent under load is on record, stating the elapsed time between the single revoking action and the last session stopping.

  1. Confirm whether a named agent can be stopped everywhere in one action. Usually it cannot.0-30 daysHead of identity
  2. Give every agent a resolvable identity that enforcement points can check.30-90 daysHead of security engineering
  3. Test revocation on a live agent under load, and time how long it takes to bite.90-180 daysHead of security operations
The evidence — 3 documents
OrganizationDocumentPosition
Cloud Security AllianceInstitution · July 2026Defining non-human identityOur reading Names issuance, rotation and revocation as a lifecycle that most estates implement only at the first step.Lifecycle of the non-human identitynames it
Palo Alto NetworksVendorUnit 42 2026 Global Incident Response ReportOur reading Names the requirement rather than conditioning it: with the fastest attacks now exfiltrating in about an hour, it asks that revoking tokens, disabling connectors and isolating a vendor's agent be decided in advance, because delays in containment come from unclear ownership and manual checks that cannot keep pace.The window revocation has to beatnames it
Cloud Security AllianceInstitutionAgentic AI Identity and Access ManagementOur reading Proposes an identity and session model in which a revocation is notified once and every enforcement point consults shared state, so that a terminated agent is blocked across protocols and integrations rather than per system.Session termination and propagated revocationproposes a fix

Issue 031 organization name it2026 evidence

Nobody can say whose authority an agent acted under

An agent acts for a person, a team or another agent. The record of which, at the moment of the action, is usually absent - so an action cannot be traced back to the human accountable for it.

This is the question an investigation asks first and an assurance review asks last, and it is hard because delegation chains are dynamic: a human asks an agent, which asks another agent, which uses a tool with its own service credentials. If only the final credential is logged, the trail stops at a machine. Carrying the originating authority through the chain is a design decision that costs little at build time and is close to unrecoverable afterwards.

How to fix it — 1 approach, 2 steps

Carry the originating human authority through every hop

Every agent action records the human or team whose authority it ultimately rests on, not merely the credential that executed it.

Done when For an agent action picked at random, the log resolves through every delegation to the human or team whose authority it rests on, not merely to the credential that executed it.

  1. Check whether one live agent action can be traced to an accountable human.0-30 daysHead of security engineering
  2. Require originating authority to be propagated and logged at each delegation.30-90 daysHead of architecture
The evidence — 2 documents
OrganizationDocumentPosition
CISAOther · April 2026Careful adoption of agentic AI servicesOur reading Names the pattern precisely: someone with low privilege induces a high-privilege agent to do what they could not do themselves, and because the action genuinely executes under the agent's trusted identity, the record it leaves reads as legitimate and pushes detection further out. Adds the credential half - keys and tokens that are static, shared between agents, or weakly held let an attacker act as the agent rather than merely through it, which defeats behavioural guardrails and the monitoring tuned to normal behaviour at the same time.The confused deputy, and the audit trail that looks finenames it
Cloud Security AllianceInstitutionAgentic AI Identity and Access ManagementOur reading Proposes explicit mechanisms for agents to establish trust and carry delegated authority, rather than each hop presenting only its own credentials.Delegation and trust between agentsproposes a fix

Who is represented

This dossier is drawn from 14 organizations working on the subject, 5 of which are cited directly in the issues above.

Consultancy — 2

Accenture 1 Deloitte 1

Institution — 4

Cloud Security Alliance 2 Association of Corporate Counsel 1 NIST 1 World Economic Forum 1

Hyperscaler — 3

AWS 2 IBM 2 Microsoft 2

Frontier lab — 2

Anthropic 1 OpenAI 1

Enterprise — 1

Palantir 1

Vendor — 1

Palo Alto Networks 2

Other — 1

CISA 1