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 operating question already exists, however. 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 is an 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.

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 reservations 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.

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. 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.