Agent identity versus agent authority.

Machine identity answers which workload, service or agent is calling and whether its credential is trustworthy. Agent authority answers what consequential action that identified actor may perform under a current, accountable delegation. Identity is the first layer, not a dispensable predecessor. Without reliable attribution, a grant cannot be matched to the actor that is using it.

A service principal may have API access to restart any cluster while the agent’s current task authorizes only observation of cluster A. The workload token can be valid and the restart still unauthorized. Conversely, a task note saying restart cluster A is meaningless if an attacker can impersonate the intended agent. Both identity and mandate must hold at the same action boundary.

An agent may run inside a workload with its own service identity. A user may have initiated the task. An API credential may belong to the platform hosting the agent. These facts should be kept distinct so attribution does not end with a generic service account.

OAuth, OIDC, SAML, MFA and sessions can help establish human or workload context. Non-human identity management adds ownership and lifecycle. These foundations matter, but a well-identified agent can still act outside its approved task.

Authority describes originating permission, delegated scope, purpose, expiry and constraints. It can be narrowed as work passes to child agents. A policy envelope further limits tools, actions, targets, value, time and operating state. The effective permission is checked at the action boundary.

This difference matters whenever a system gives an agent a broadly capable tool. “The agent is trusted” is not a sufficient description of which changes it may make.

An incident review should connect the caller’s identity to its owner and task, then trace the authority origin and delegation chain. It should also show the applicable policy, decision and execution result. This makes failures of attribution distinct from failures of authorization.

Long-lived service credentials are useful for reliable workloads, but they do not know when a human cancels an agent task or changes its scope. If an agent uses a shared workload identity, the downstream API may see only the workload. To reconstruct authority, the architecture must preserve the agent and task attribution alongside the credential, without trusting a free-form claim supplied by the agent itself.

The design should also distinguish suspension of the identity from revocation of one grant. Disabling a workload account can disrupt unrelated services; cancelling a grant should stop the specific action path. Both are necessary controls, but they solve different operational problems.

A cloud API may see one service principal even when several agents share the runtime. The runtime should preserve which logical agent and task initiated each request, while the receiving system verifies that attribution through a trusted channel. A free-text agent name inside a tool argument is not an identity proof. Ownership, credential issuance, rotation and retirement still belong in the non-human identity inventory.

Consider an operations agent that can read cluster health. Its workload credential may also reach a restart API because the service uses one broad role. The identity question is whether the request really came from this workload and logical agent. The authority question is whether the current task permits restarting this cluster. Conflating the two leaves a valid credential acting on an unauthorized task.

If attribution is missing, improve the binding between the human or organization, the task, the logical agent, and the runtime credential. If permission is missing, define a narrower grant and enforce it before the action. Disabling a shared credential to cancel one task can disrupt unrelated work; revoking only a task grant should stop that task without changing the workload identity.

In an incident review, ask for the credential issuer, principal owner, task origin, delegated grant, policy version, action target, decision and execution outcome. This sequence exposes whether the fault was impersonation, overbroad access, an invalid delegation or an enforcement bypass.

An enterprise workflow may involve the initiating human, the logical agent, the workload hosting it and the API client credential. They are related but not interchangeable. The human may approve a task without directly calling the API. The workload may authenticate the connection while several agents share it. The API credential may have broad technical reach. A good evidence record preserves those relationships and the accountable owner.

NIST’s 2026 concept work explicitly raises how agents should prove authority for specific actions and how actions bind back to human authorization. That is a research and interoperability question, not a statement that one vendor has already solved it. ProofGrid’s existing identity and access foundation can supply part of the attribution path; ProofGrid’s authority graph makes the task mandate explicit.

OAuth scopes constrain token access to API capabilities. RBAC describes permissions assigned to roles. ABAC can evaluate contextual attributes. These mechanisms remain useful and may enforce pieces of the final rule. A task-bound authority grant adds the originating purpose, specific outcome, parent chain, expiry, approval and revocation relationship that a broad machine credential may not carry.

A grant should be issued through a trusted channel. A downstream service should verify or resolve it, not accept the agent’s free-text declaration that its user approved the action. If a grant is revoked, the service account need not always be disabled; stopping that task’s authority can preserve unrelated workloads while preventing the protected effect.

Human H opens incident I and authorizes agent A to inspect endpoint E. A runs in workload W and calls security API P. Identity records establish H, A and W, and P authenticates W. The task grant permits read operations on E until 18:00. A later request to isolate E is a different action and requires a separate grant or approval. A request to isolate adjacent endpoint F exceeds the target scope even if the same API credential can reach F.

At review time, ask whether the identity chain was sound, whether the authority chain existed and remained valid, which policy applied, what decision occurred, and what the endpoint tool actually did. Those questions separate impersonation, excessive standing access, unauthorized delegation and ordinary execution failure.

Inventory non-human identities with ownership, issuer, rotation and retirement. Bind logical agents to trustworthy runtime identities. Keep task grants narrow and short-lived, validate ancestor revocation and preserve context through queues and tool servers. For high-impact actions, bind approval to exact actor, tool, target and parameters; do not let an older approval float to a changed request.

If identity is compromised, suspend or reauthenticate the principal as appropriate. If only a task is cancelled, revoke the task grant and its descendants. If risk increases but the original mandate still stands, policy may temporarily degrade writes to reads. These are distinct control actions, and collapsing them into “trusted agent” hides the response needed.