Limit the Technical Authority of AI Agents

NIST launched the AI Agent Standards Initiative on February 17, 2026, and updated its working page in August. In parallel, the National Cybersecurity Center of Excellence is using a concept paper to examine how software and AI agents can be identified, authorized, and connected to human authority. The document is labeled a draft, and the project remains in a Reviewing Comments state. It is not a completed NIST security standard.

The enforceable boundary can already be identified for agent operations. An agent may read data, draft a message, or construct a tool call, but a business state changes only when a connected service accepts and executes that call. The technically enforceable boundary sits there. Neither the model's explanation nor the tool description enforces access control.

Identity, Authorization, and Payload

A dedicated, managed non-human identity can improve attribution. Shared credentials or an unchanged inherited user session make it difficult to determine which automated actor acted, under whose delegation, and for what task. The NCCoE paper addresses the relationship among non-human identity, authorization, delegation, and auditability but does not yet prescribe a single token or approval scheme.

The receiving system should evaluate identity, permission, destination, and parameters under its own rules. Narrow operations are easier to constrain than arbitrary database access or a broad write grant. Short-lived credentials can further restrict access to named resources, actions, time windows, and maximum values. This architecture is an editorial security recommendation derived from the draft, not an approved NIST requirement. For consequential actions, approval of an agent-written summary is not enough. The reviewer should see the actual payload to be executed. If the recipient, amount, target record, or another decision-relevant parameter changes afterward, the earlier approval no longer matches the action. A new decision binds authority to the current content.

Existing OAuth mechanisms can support these limits. RFC 8707 describes binding an access token to a particular target resource. A token intended for one service should therefore not be freely usable at another. This audience restriction does not replace checks on the permitted operation or its parameters. It also does not, by itself, prevent a stolen bearer token from being used at its intended recipient. RFC 9396 introduces more detailed authorization data through authorization_details. Its payment example includes the amount, currency, and recipient. The specific API must define what those details mean and how they are enforced. A valid JSON object therefore does not itself confer effective authority. The granted consent must be connected to enforcement by the authorization server and the target system. These standards provide technical building blocks; they are not NIST requirements specifically for AI agents.

Untrusted Inputs

Indirect prompt injection can enter the agent's context through email, a document, a website, or another tool's output. OWASP's agentic risk framework includes Agent Goal Hijack, Tool Misuse and Exploitation, and Identity and Privilege Abuse. It is neither a law nor an official technical standard, but it describes the relevant threat categories.

An instruction hidden in a document should therefore be unable to grant new rights or redirect an approved data destination. Narrow schemas, allowlisted targets, isolated execution, short-lived credentials, and read-only modes can reduce exposure. They do not guarantee resistance to manipulation or factual correctness. The target service still has to deny a call that falls outside the grant, independently of the model text. With low-trust inputs, the agent can initially produce only a reviewable draft while tools that write data or trigger actions remain disabled.

Pilot Operations and Retries

A bounded operating approach can begin with a limited data set and an existing manual fallback. The agent may first analyze cases, then prepare a draft, and only later receive permission to make narrowly defined changes after the organization has operating evidence. NIST and OWASP do not mandate this sequence. It is intended to keep unknown risk and effective authority from increasing at the same moment. The task, sources used, authorization decision, tool call, and outcome should remain traceable without copying confidential material indiscriminately into a second store. Protected references and technical identifiers may be sufficient when they allow the executed transaction to be investigated. What data may be retained, and for how long, depends on the specific system and the rules that apply to it.

Multi-step workflows also need a retry strategy. If an agent fails after a tool call, it may submit the same step again. Payments, orders, or accounting entries can then be duplicated.

The target system should recognize when a repeated call represents the same business action and, according to the process, reject it or return the result that already exists. The evidence belongs in the system where the effect occurred, not only in the model transcript. A connection failure after a call leaves open whether the change was already applied and only the response was lost. RFC 9110 limits automatic retries of non-idempotent methods to cases where the client knows the application semantics are idempotent or can determine that the first attempt was not applied. For agent operations, this means a tool error alone does not justify a second payment or order. If the application semantics do not guarantee a safe retry, the client must first establish whether the original transaction was executed.

The AWS Builders Library describes a contract using a request identifier supplied by the caller. The same caller can repeat the same request under that identifier. Comparing parameters alone would be insufficient: two identical orders may intentionally represent two separate transactions. The identifier captures the intent of the individual operation. In the described approach, recording the identifier and making the business change form one atomic operation. Otherwise, an effect could exist without its record, or a record without the effect. If the same identifier returns with changed parameters, the service responds with a validation error. Retention of these identifiers also needs to account for late retries.

For an agent task that resumes after interruption, the resulting recommendation is to retain the existing request identifier and provide a way to retrieve the result already created in the target system. This is an application-level contract, not a general promise of exactly-once execution for arbitrary tool chains.

Revocation and Transparency

An emergency stop is effective only if it prevents new steps, pauses queued work at controlled points, and revokes delegated credentials.

The NCCoE paper treats revocation as an architecture question but does not define a finished kill-switch standard. A production exercise supplies the local evidence: stop an active job, check the credentials, and establish the resulting state in the target system. RFC 8693 identifies a limit of delegated tokens: token exchange does not automatically link their lifecycles. Revoking the original token therefore does not necessarily revoke a token already issued from it for a downstream service. Whether and how revocation propagates depends on the implementation. The proposed emergency stop must therefore also test which delegated access remains effective after the agent stops. Ending its process and revoking its authority require separate evidence.

Transparency to affected people is a separate legal issue. Article 50 of the AI Act may require notice or disclosure for direct interaction or certain published content. A label does not grant system authority, and sound authorization does not by itself satisfy a transparency duty.

Note: This assessment is not a substitute for a review of the specific case.