Reusing a Human Login Cannot Govern an Agent's Authority

Consider an explicitly hypothetical case: a purchasing employee logs into a SaaS product, and an agent reuses that browser session to move from preparing an order to submitting it. This is not a case from a real company. If both use the same session cookie, the SaaS sees the employee as the actor and cannot separately express the operations allowed only to the agent, an agent-only lifetime, or an agent-only stop.

A 2026 NIST/NCCoE paper places distinct human and software or AI agent identities, delegation from a specific user, agent-specific entitlements, attributable agent actions, and identity creation, update and revocation among the areas that need implementation work.[1] It is, however, a DRAFT concept paper—not a completed standard or an empirical study of control effectiveness.

The problem is not that authority originates from a person. The OpenID Foundation whitepaper focuses on opaque impersonation that cannot distinguish the user principal from the agent actor.[4] Giving an agent a raw session, password, or broad bearer token, without distinct actor identification or client binding, lets the fact of authentication expand into the agent's operating authority.

OAuth delegated authorization separates the resource owner, client, authorization server and resource server, and can issue a constrained token from user consent or organizational policy. RFC 9700 recommends restricting tokens to an audience, resource and action and checking those restrictions on every request.[5] A grant therefore need not be rejected merely because the agent acts on a person's behalf.

What can be accepted is not the human login state itself, but a grant derived from it: audience-bound to the target server, down-scoped to what is needed, short-lived, and bound to a client or sender. When the agent actor remains identifiable and can be renewed or revoked separately, human-derived authority is different from raw credential reuse.[4][5]

As this article's low-risk boundary, a local read-only tool invoked over STDIO from an isolated OS account and unable to change external state need not use an OAuth delegation record. MCP core authorization is optional across the protocol and primarily addresses HTTP transport.[2] The design still needs another authority boundary defining what the tool can read and who can stop it.

Authentication establishes who—or which workload—is present. Authorization decides whether that actor may perform this action on this resource, for this audience, under these conditions and until this expiry. MCP core 2026-07-28 requires servers to check on each HTTP request that a token was issued for them (audience) and is valid and unexpired, and defines a recommended insufficient-scope challenge and a step-up flow.[2]

The Enterprise-Managed Authorization extension exchanges an enterprise IdP identity assertion for an ID-JAG addressed to the resource authorization server and then obtains an access token for the MCP server. The ID-JAG example retains the user subject, client, audience, resource, scope, issued time and expiry.[3] EMA is not MCP core, and its Identity Assertion JWT Authorization Grant and identity-chaining foundations were IETF Internet-Drafts at the review date.

From these components, this article proposes an agent authority delegation record that binds the human principal, agent or workload actor, client binding, resource, action or scope, audience, conditions, issued time and expiry, approval, and revocation handle. No single reviewed standard mandates that complete field set; it is a Catalysphere synthesis that turns several primary sources into an implementation decision.[2][3][4][5]

A delegation record has no control effect if the execution target never evaluates it. RFC 9700 calls for resource servers to check audience, resource and action restrictions on every request, while MCP core rejects tokens that are not intended for the target MCP server or are invalid or expired.[2][5] Approval at issuance is not a substitute for an execution-time decision.

Effective authority is the intersection of the ceiling in the delegation record, runtime policy, and the controls the downstream system can actually enforce. A grant may say “draft only,” but if the SaaS exposes one coarse scope for both reading and sending, that sentence alone cannot prevent submission. Expose the gap: restrict the operation through a proxy, retain exact-action approval, or reject the automation.

MCP's step-up flow directs the client to request the union of its previously requested scopes and the newly challenged scopes, so cumulative scope requests are the specification's default (the authorization server still decides what is granted).[2] This article deliberately departs from that default: keep elevated authority out of the standing grant by treating it as a separate credential bound to the target operation and a short expiry, then reevaluate the next operation.

• Enforcement rule: check restrictions on every request at the resource server or a trusted proxy
• Gap rule: do not approve a condition as implemented when the downstream system cannot enforce it
• Step-up rule: bind added authority to the operation and a short lifetime instead of creating standing privilege

Asking “Proceed?” before a high-impact action leaves the object of approval ambiguous. Catalysphere recommends binding approval to the pending action's resource, operation, material parameters, impact ceiling, expiry, agent identity and policy version. If the target or parameters change after approval, the system should not reuse that approval; it should evaluate the changed action again.

In the hypothetical purchasing case, “allow use of the purchasing SaaS” is too broad. Fix whether the agent may only draft or may submit, together with supplier, amount ceiling, quantity, duplicate-prevention key and validity window, then execute only if the pre-submission state still matches. This is not a method with demonstrated effect. It is an operating design intended to reduce false approval caused by drift between the approved and executed actions.

Conversely, a dialog before every low-risk, read-only, reversible and rate-limited operation can create approval fatigue and erase useful automation. Decide whether to permit a bounded standing grant from state change, reversibility, impact ceiling and verifiability. Every exception needs an owner, rationale, compensating control, expiry and review trigger so it does not become a permanent scope expansion.

• Approval rule: bind approval to the agent, resource, operation, material parameters, ceiling and expiry
• Change rule: invalidate approval and reevaluate when the target or parameters change
• Exception rule: give every exception an owner, compensating control, expiry and review trigger

A short-lived token reduces exposure time but does not itself propagate a policy change immediately. The stable EMA extension specifies an expiring ID-JAG and an audience-bound access token, but it does not define a protocol or deadline for immediately invalidating downstream tokens already issued.[3] That is why an “immediate” statement on a documentation page should not be treated as a normative guarantee.

The OIDF whitepaper likewise says prompt revocation across offline or multi-hop delegation chains is largely unsolved.[4] Revoking the agent credential, stopping refresh, deprovisioning the actor identity, and removing residual entitlements are separate state transitions. Deleting the agent identity is not proof that every issued token and downstream grant has stopped.

This article treats renewal as a new decision about the principal's status, agent version, purpose, resource, scope, conditions and exceptions—not as a mechanical extension of expiry. When revocation cannot reach every component promptly, combine compensating controls such as short token lifetimes, introspection, gateway denial and credential-family shutdown, and disclose the remaining delay in the release decision.[1][4][5]

An agent authority delegation record is an input to an authorization decision, not evidence of security effectiveness. The production owner owns the record; the IAM or resource owner approves actor and resource boundaries; the business control owner approves action and transaction constraints; and the security owner approves token binding and revocation paths. Internal audit later tests the evidence independently rather than acting as a routine co-designer.

Acceptance should run denied, expired, changed, replayed and revoked requests before celebrating the happy path. Test whether agent-only suspension blocks machine authority without interrupting the human's normal use, whether a parameter change after approval is rejected, and whether refresh and downstream calls fail after revocation. If immediate revocation cannot be guaranteed, reduce authority to operations whose residual window is tolerable.

A token rollback cannot undo an irreversible external effect. Submitted orders, notifications or transfers require cancellation, compensation, and a reconciliation owner and deadline rather than a claim of technical rollback. This article covers grant, constraint, renewal, expiry and revocation. Detailed execution-log payloads, retention, access and deletion belong in a separate audit-log contract.

• Acceptance rule: withhold production authority until denied, expired, changed, replayed and revoked tests all pass
• Owner rule: separate production, IAM or resource, business-control and security responsibilities in the record
• Rollback rule: assign an owner, procedure and deadline for cancellation or reconciliation of irreversible effects