NIST AI Agent Authorization: Five Asks Mapped to Kubernetes

NIST has published no AI agent authorization standard, and nothing in its February 2026 draft gives an auditor a control to test. What the NCCoE did publish is more useful to a CISO with an audit on the calendar: five areas of interest that read like an assessor’s question list. Together they ask which agent acted, on whose behalf, under what authority, and with what record. A Kubernetes cluster has a primitive it can point to for each area. Those primitives settle whether an action was allowed, stop short of what the agent did with that permission, and record the user an agent acts for only when the call goes through the Kubernetes API.

What follows covers what NIST has actually published, the five areas of interest, each area against a Kubernetes primitive, where “was it allowed” stops being the question, why access delegation is the weakest mapping, and what to put in place now.

What NIST has actually published

The document is a draft concept paper titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, dated February 2026 and written by Harold Booth, Bill Fisher, Ryan Galluzzo and Joshua Roberts. It asks the community whether the NCCoE should demonstrate how existing identity and authorization standards apply to AI agents, and what that demonstration should cover. Its comment period ran from February 5 to April 2, 2026. The NCCoE project page still lists the status as Reviewing Comments.

The paper sets no controls. If the project proceeds, planning could include a draft project description and a call for collaborators, and the intended deliverable is a practice guide: example implementations built in the NCCoE lab from commercially available technology.

Its scope is drawn around agentic architectures, meaning systems that take instructions, pull in more context from other resources, process it, and may act before returning a response. Retrieval-augmented generation (RAG) architectures are out of scope, and so are architectures that use only an LLM and its training data. An agent running as a Kubernetes workload and calling tools sits inside that scope.

Two related NIST efforts are easy to confuse with the paper. The AI Agent Standards Initiative, launched by NIST’s Center for AI Standards and Innovation (CAISI) on February 17, 2026, is the umbrella program, with three pillars: industry-led standards, community-led protocols, and research into agent identity and security. The initiative lists the concept paper as one of its activities. CAISI also ran a separate Request for Information on securing AI agent systems, which closed on March 9, 2026.

The five areas of interest

The paper names five focus areas: identification, authorization, access delegation, logging and transparency, and tracking data flows. In that order they follow an agent from who it is, to what it may do, to the person it acts for, to the record it leaves, to where its instructions came from.

Identification

Identification asks how an access management system can tell an agent from a human and manage the range of actions the agent takes, from steps a human approves to fully autonomous responses. The paper’s questions for reviewers go further: what metadata an agent identity needs, and whether that metadata stays fixed or changes with each task. Those are questions about naming a principal, and they stop short of which Kubernetes object should carry an agent’s behavior over time.

Authorization

Authorization covers how rights are granted to agents and how access decisions are enforced on the agent’s identity, using OAuth 2.0 and its extensions alongside policy-based access control. The reviewer questions include the hardest one for a security team: how to establish least privilege for an agent “when its required actions might not be fully predictable” at deployment. A working answer already exists in least privilege derived from behavior, where observed actions set the boundary.

Access delegation

Access delegation links a specific user’s identity to the agent acting for them, so delegation stays controlled and every automated action stays accountable to a person. The reviewer questions call this the “on behalf of” scenario and ask how agent identity binds to human identity when a human approves a step.

Logging and transparency

Logging and transparency ties each agent action to the agent’s non-human identity and asks for visibility into the actions taken, the data generated, and the outcomes. The reviewer questions raise the bar: agent logs should be tamper-proof and verifiable, and non-repudiation should reach back to the human who authorized the work. Read as an evidence requirement, this area wants a record the agent cannot edit, attributed to a stable unit such as the object an agent’s actions are attributed to, with the depth set out in what an agent audit trail needs.

Tracking data flows

Tracking data flows asks for the provenance of user prompts and data input sources, so that decisions about an agent’s next action can account for where its instructions came from. An agent that reads a ticket, a document and a tool response before acting has three inputs, and this area wants to know which one shaped the action. The raw material sits in tool call records, which capture what went into each invocation and what came back.

Each area against a Kubernetes primitive

A cluster running agents already has a nearest primitive for all five areas. The table sets each area against that primitive, what it answers, and what it leaves open.

Identification and authorization map most cleanly, because service accounts and RBAC were built for the question the paper asks: a non-human principal and a decision about its rights. Logging and transparency stops at the API server, and tracking data flows stops at the network destination. Access delegation barely maps at all.

Where “was it allowed” stops being the question

An agent’s pod starts with a database credential mounted from a Secret. Admission control, RBAC and the audit log all did their jobs when that pod was created. From then on, the agent reads the credential from a file, queries the database, writes the results to local disk, and sends them to an external endpoint. None of those four actions is a Kubernetes API request, so the audit log holds the pod’s creation and nothing after it.

Every primitive in the table governs or records permission. The paper’s logging area asks about the use of that permission: the actions taken, the data generated, the outcomes. An assessor who asks what an agent did with its authority is asking for a record that begins where the API server’s record ends.

That record cannot come from cluster configuration, and it should not come from the agent. A framework log is written by the agent’s own process, which is the thing under review. The evidence the paper describes, tamper-proof and verifiable, has to be captured below the API server and outside that process. Runtime behavioral security supplies that layer: process, file, network and identity activity observed through eBPF at the kernel, attributed to each agent. Each agent’s activity is compared against its own baseline, which ARMO holds at the Deployment level as Application Profile DNA (APD™). One record then answers both halves of the logging area, what the agent did and whether it departed from what it normally does.

Access delegation is the weakest mapping

Kubernetes has no native notion of an agent acting for a user. Impersonation comes closest: an identity granted the impersonate verb can send API requests as a named user, and the audit event records both identities. Standard impersonation hands over all of that user’s rights. Constrained impersonation, an alpha feature in Kubernetes v1.35, adds a second check so the impersonator can be limited to specific actions. Both versions cover only calls to the Kubernetes API.

Most work an agent does for a person happens elsewhere, in a ticketing system, a code host or a database, and the credential the agent presents there, whether a projected service account token exchanged through workload identity or a key issued to the workload, names the workload and says nothing about the person who asked. The link the paper wants, user to agent to action with both identities intact, has to be carried by the application and the identity provider. The cluster will not produce it.

What to put in place now

Four pieces of preparation hold whatever the final project description says, because each answers a question the five areas already ask: attribution, evidence independence, enforcement state, and a delegation record.

Attribution means every agent action resolves to one named agent. No two agents share a service account, and each agent’s alerts and history attach to a workload that survives restarts, so “which agent” has a single answer at the moment an assessor asks it.

Evidence independence means the record of what an agent did comes from a source the agent has no way to alter. Capture process, file and network activity outside the agent’s process, and store it where the agent’s service account has no write access.

Enforcement state means you can show, for each agent, which policy applies, whether it runs in observation or enforcement, and when that changed. A written policy tells an assessor what was intended. Documented enforcement shows what the control allowed and blocked at runtime.

A delegation record means that, for every agent acting for users, each task names the user who started it, carried from the application or identity provider into the same timeline as the agent’s actions. Where that link does not exist yet, list which agents act for users and through which mechanism. A delegation review starts with that inventory.

The questions are already written; the evidence takes longer

The five areas may be renamed before a project description appears, and the standards the paper lists may change with them: MCP, OAuth 2.0 and 2.1, OpenID Connect, SPIFFE/SPIRE, SCIM and NGAC, alongside NIST SP 800-207, SP 800-63-4 and NISTIR 8587. The questions underneath are older than the paper. Every access review already asks which user acted, on whose authority, and with what record. The paper extends them to a new kind of principal.

Configuration answers can be assembled in the week before an audit. Behavioral evidence cannot, because a record of what an agent did last quarter exists only if something was recording last quarter. That makes it the preparation with the longest lead time, and the one to start first. ARMO’s runtime behavioral security for AI workloads captures that record per agent, below the API server and outside the agent’s own process. Book a demo and walk one of your agents through the five areas: what it did, which policy applied, and what an assessor would be shown.

FAQ

Is there anything to comply with today? No. The NCCoE document is a draft concept paper asking for feedback on a possible demonstration project, and its comment period closed on April 2, 2026. If the project proceeds, its output is a practice guide of example implementations, which organizations can choose to adopt. Assessors can still use the five areas as a question list, so the evidence is worth building before any text is final.

How do we identify an AI agent distinctly from the workload it runs in? Kubernetes has no identity type for agents, so an agent is identified through the workload that runs it. Give each agent a dedicated service account so its API calls name that agent alone. Record agent metadata such as owner, model and connected tools in labels and annotations, and put changes to them under review. For detection and investigation, attach the agent’s behavior to a workload object that survives pod restarts.

What does “on behalf of” delegation look like in a cluster? Inside the cluster, the only mechanism is impersonation, which lets an identity act as a user at the API server, with that user’s full rights unless the alpha constrained impersonation feature narrows them. Delegation to external services is carried by tokens the application obtains from the identity provider, and the cluster does not see it. The practical step today is an inventory of which agents act for users, plus a record that links each task to the user who started it.

Are Kubernetes audit logs enough for the logging and transparency area? They cover one part of it. The API server audit log records which identity called which Kubernetes API and whether the call was allowed, and cloud audit logs do the same for cloud APIs. Most of an agent’s work, including file reads, outbound connections and tool calls, never reaches the Kubernetes or cloud control plane. Covering that part needs a runtime record captured outside the agent’s process.

What should we do before the project description is published? Build the four pieces that hold whatever the final text says: attribution of every action to one agent, evidence captured independently of the agent, a record of each agent’s enforcement state, and a delegation record for agents that act for users. Start with the evidence, since a record of past behavior cannot be created after the fact. Then check what you have against the five areas so the gaps are known before an assessor finds them.NIST AI Agent Authorization: Five Asks Mapped to Kubernetes