Blog · June 22, 2026

Identity and authority: who the agent is, and what it can do

Five Security-domain identity controls (IA-01 to IA-05) that decide which agent acted and what it was allowed to do, federating with peer domains.

apeiris.ai·The Seams series · originally June 2026

When something goes wrong with an agent, the first question is always the same. Which one did it, and how did it have the access to do that? If you cannot answer fast, you have already lost time you did not have. This layer is about being able to answer.

Five controls sit here. They build on each other, roughly in order, so I will take them that way.

Give every agent its own identity

Each agent gets its own name badge, so you always know which one did what. Be precise about what "each agent" means, though, because these systems spawn and delegate: give the stable, logical agent a governed identity, and give each runtime instance or delegated task its own short-lived credential tied back to that identity and its parent.

This failure mode shows up repeatedly in current agent deployments and vendor guidance. An agent runs under a developer's personal login, or a dozen agents share one service account. The moment that happens, the agent inherits far more access than it needs, and when something breaks you cannot tell the agents apart.

The fix is to register each agent as its own identity in your directory or identity system, and have it authenticate as itself, never as the human who started it and never as a shared account. Bind that identity to a credential that is cryptographically verifiable and rotates on its own. A common building block is a SPIFFE SVID, which you can think of as a short-lived, automatically issued ID card for a piece of software. Tie each identity to an owner, a purpose, and a permitted scope, so you can govern it and switch it off later.

This is also where the standards work is heading: NIST's NCCoE concept paper on agent identity and the Agent Standards Initiative both build on cryptographic agent identity (SPIFFE, DIDs). Building it now gets you ahead of where the guidance is going.

What to avoid: agents running as your own user account, one shared account across many agents, an identity that never expires.

How you would prove it: inventory every running agent and confirm each runtime instance maps to one governed logical-agent identity, with its own short-lived credential and parent-task lineage. Then test it. Have agent B try to authenticate as agent A, and confirm it is rejected. Keep the agent register diffed over time as your evidence; it shows issuance, rotation, and de-provisioning.

Operational profile (IA-01). Enforcement point: the identity provider / directory plus a workload-identity issuer (for example a SPIFFE/SPIRE control plane). Identity is bound at issuance, outside application code, never minted by the agent itself.

Hand out short-lived, task-scoped keys

Give the agent a day-pass for one job, not a master key it keeps forever.

Long-lived API keys are a common and high-impact way non-human identities get abused. (A non-human identity is any credential that does not belong to a person: a service, a script, an agent.) The secret leaks, or the agent gets hijacked, and the access is still valid weeks later.

So the agent should hold no reusable, long-lived secret of its own (some hardware- or platform-backed mechanism still has to bootstrap its identity, but that is attested, not a copyable key). When it needs to act, it presents its own identity (the one from the first control) to a broker, which mints a token scoped to a single tool or resource and set to expire in minutes. The broker hands over that short-lived credential at the moment of use. The mechanism behind this is OAuth token exchange: it provides the swap, but your authorization policy is what makes the resulting token actually narrower and shorter-lived. Worth knowing the ground is still settling here: the broader umbrella the industry is converging on, OAuth 2.1, is at this point an IETF draft rather than a final standard, even as vendors build on it today.

What to avoid: static keys in config files, environment variables, or the repo; one token reused across tasks; refresh tokens that outlive the work.

How you would prove it: scan the host, environment, repo, and config for any credential whose lifetime is longer than your policy allows, and aim for zero. Then replay a captured token after it expires and outside its scope. Both must fail. Your evidence is the broker's issuance log: who got what scope, for how long. That same log is the kind of record EU AI Act Article 12 calls for, subject to how the obligation applies to your system.

Operational profile (IA-02). Enforcement point: a token broker / authorization server performing OAuth token exchange. The minting key lives in the broker, outside the agent's reach; the agent only ever holds the short-lived token it was handed.

Act on the user's behalf, and ask before anything risky

The agent borrows the user's permission for a job, and must ask before doing anything risky.

When an agent acts for a person, there is a right way and a wrong way to carry that authority, and this is not just my framing. The distinction is written into the standard. OAuth token exchange (RFC 8693) defines two separate modes. One is impersonation: the agent simply becomes the user, and nothing in the token records that an agent was ever involved. The other is delegation: the token names both parties at once, the user as the subject (on whose behalf) and the agent as the actor (who is actually doing it), through what the spec calls the act claim. The same standard even has a may_act claim for stating, in advance, who is allowed to act on whose behalf. So "an agent acting for a user" has a precise, checkable shape. You do not have to settle for the agent quietly wearing the user's face.

That distinction is exactly where the identity industry is putting its weight. The center of gravity has moved from authentication, proving who something is, to authorization that runs continuously and carries delegation with it. Okta has shipped Cross App Access, an OAuth extension built specifically for agent-to-app delegation, and NIST's NCCoE concept paper on agent identity and authorization proposes building on OAuth as the foundation. The point is not which vendor you pick. It is that the building blocks for real delegation now exist, which means impersonation is a choice, not a necessity. One practical caveat for the messy middle: when a downstream legacy system cannot parse the act delegation claim, the broker should down-scope the active session token to the single context of that exact request, so the on-behalf-of boundary still holds even where the claim itself does not survive.

On top of delegation, sensitive actions should trigger an explicit approval out of band, like a push to a separate device, instead of being silently auto-approved inside the agent's loop. This matters most under prompt injection, where hidden instructions in the agent's input try to push it past what the user actually intended. A tight on-behalf-of scope plus a real approval gate is what stops the agent from quietly doing more than it was asked.

What to avoid: impersonation with no record that an agent acted; one broad consent that covers every future action; sensitive actions auto-approved inside the loop.

How you would prove it: inspect the token-exchange setup and confirm the token carries the user as subject and the agent as actor, delegation rather than impersonation. Then feed the agent a prompt-injection payload aimed at an action the user never authorized, and confirm both the scope and the approval gate stop it. Your evidence is an approval log linking each sensitive action to the human who approved it and the delegated token that carried it.

Operational profile (IA-03). Enforcement point: the authorization server that issues delegated (act-claim) tokens, plus an out-of-band approval service for sensitive steps. Both sit outside the agent's loop so a hijacked agent cannot self-approve or rewrite the on-behalf-of scope.

Check permission on every action, not just at login

Keep asking "are you still allowed to do this?" on every action, not only at the start.

An agent authorized once at the start of a session can drift. It keeps acting on permissions that should have been pulled. Whatever enforces at the moment of action is your real point of control, not the check you did an hour ago.

So put a policy engine in the path of every tool call, and decide based on live conditions (the task, the risk, the time, what the agent has already done) rather than a token issued once at login. Two terms worth knowing: ABAC, attribute-based access control, which makes decisions from current attributes rather than a fixed role; and NGAC (Next Generation Access Control), a standardized way to express those policies as live relationships between users, resources, and conditions rather than fixed roles. When policy changes, it should revoke authority that is already in flight, not just future sessions.

There is a subtle trap worth calling out: check the running chain of actions, not just the single call in front of you. A sequence of individually allowed steps can add up to a goal the agent was hijacked into pursuing.

What to avoid: authorizing once and trusting it for hours; policy changes that only apply to new sessions; the agent deciding for itself whether it is allowed.

How you would prove it: mid-task, revoke a permission and confirm the agent's very next tool call is denied rather than riding the old session. Your evidence is the per-call decision log: for each tool call, which policy version was evaluated and whether it was allowed. Instant revocation, by the way, is your fastest way to contain an agent short of killing it outright.

Operational profile (IA-04). Enforcement point: an in-path policy decision point (PDP) evaluated on every tool call (ABAC/NGAC), external to the model loop. It is the thing that enforces at the moment of action, so revocation lands on the next call rather than the next session.

In a real deployment the broker from the second control and the policy engine from this one usually ship as one in-path enforcement gateway: policy decides first, then the broker mints only the credential that decision allows. That gateway is the concrete home of several controls at once, and I describe it as the agent runtime enforcement plane in the overview.

Find every agent, including the ones nobody told you about

Keep a live list of every agent running, including the ones nobody told you about.

You cannot protect what you cannot see. Unmanaged "shadow" agents, the ones spun up without the security team's knowledge and often with real system access, are a standing risk, and they are frequently the first sign of something rogue or compromised.

This is not hypothetical. In a 2026 CSA and Strata Identity survey, around 40% of practitioners already had agents in production, with ownership split across security, IT, and AI teams. That fragmentation is exactly the condition where agents get spun up faster than anyone keeps track of them.

The approach is to continuously reconcile the identities you issued (back at the first control) against the agent processes you actually observe, on endpoints and in your SaaS apps. Any agent with system access and no issued identity is a finding: bring it under governance, or shut it down.

What to avoid: a manual spreadsheet of agents; discovering agents only during an incident; unregistered agents with no owner.

How you would prove it: spin up an unregistered agent with a real key and confirm your discovery flags it inside your detection window. Your evidence is a periodic reconciliation report, discovered agents versus issued identities, with the gap list and how it was closed.

Operational profile (IA-05). Enforcement point: an identity-governance / discovery plane that continuously reconciles the identities you issued against the agent processes actually observed on endpoints and in SaaS apps. It is a detective control, so its value is the size of its blind spot and how fast it closes the gap.

Where this layer runs out

Everything above holds inside your own organization. The moment your agent calls an external agent or a vendor API you do not control, these guarantees stop at the boundary. That is the first of the three gaps I think no framework closes yet, cross-organization identity federation, and it is worth its own conversation.

The handoff

Identity issues and brokers authority, then hands it to the protocol and containment layers the moment the agent calls a tool or another agent. The invariant that has to survive the handoff is the agent's scope, and it often does not survive cleanly: a delegated token can be over-broad for the downstream call, and the moment it crosses an organizational boundary (the first of the three gaps) your revocation and attribution stop traveling with it. The evidence that must cross is which identity acted, on whose behalf; if the next layer logs only "a request arrived," the thread is lost. Who owns the failure when an external agent misuses a token you issued? Today, no one clearly. The concrete test: your agent presents a correctly delegated, read-only, five-minute token to a partner's A2A endpoint, does that intent survive into their environment, or widen the moment it lands?

Update · July 2026
Since this post (June 2026), that missing evidence layer is what we are building as the Apeiris evidence fabric. These identity controls now sit in Security, one of 12 domains, and the peer concerns have become their own full domains that they federate with. Agent identity issuance and discovery federate with the Identity domain; delegated on-behalf-of authority with the Authority domain; the per-action injection and approval gate with the Agentic domain. Apeiris defines the signed attestations that let scope, delegation, and attribution survive the handoff as evidence rather than a request that merely arrived, and the mapped-versus-satisfied proof is executable at /prove/.

If identity is the layer you find emptiest, it is a good place to start, because it is the foundation the other five layers lean on. You can see just these Security-domain identity (IA) controls, with the standards, the products that build them, and the validation steps, at apeiris.ai.

Sources

Apeiris Identity →Apeiris Security →