· Security
I've Been Building AI Agent Authorization. NIST Just Caught Up.
NIST wants agent identity, an authorization check before each action, and auditable receipts. All three are implementable now, without waiting for the standard to finalize.
Something is happening at the policy layer that most developers haven't noticed yet.
On February 5, 2026, NIST's National Cybersecurity Center of Excellence published a concept paper titled "Accelerating the Adoption of Software and AI Agent Identity and Authorization." The public comment period closed on March 9, 2026. If you're building agentic systems and you haven't read it, you should.
Not because it mandates anything: it doesn't, yet. The reason to read it is that the questions NIST is asking are exactly the ones your production systems should already be answering.
AI agents require verifiable identity, pre-action authorization, and auditable receipts. Those three requirements are implementable today, without waiting for any standard to finalize.
Here's what the paper says, why it matters, and what you can implement today.
TL;DR
- NIST published a concept paper on AI agent identity and authorization in February 2026; public comment closed March 9
- The paper identifies three requirements: agent identity, action authorization, and auditability
- These are not new ideas; fintech has been doing this for years
- You don't need to wait for the standard to finalize; you can implement all three this week
- The builders who ship this now won't be scrambling when it becomes a baseline expectation
What NIST is actually proposing
The paper was written by Ryan Galluzzo (who leads NIST's digital identity program), Bill Fisher, Harold Booth, and Joshua Roberts. Its core argument: AI agents are a new category of digital actor that existing identity governance was not designed for.
For years, we've used service accounts, API keys, and OAuth tokens to control what software can do. That worked when software followed a deterministic script. An AI agent is different. It can reason over data from multiple sources, decide what to do next, and execute across systems, all without a human approving each step.
The paper frames the central challenge this way: how do you trace what an AI agent did back to the human authority who authorized it? Not approximately. Not "the agent was prompted to do this." Specifically, verifiably, and at any moment.
NIST identifies three things every agentic system needs. I'll use their framing, then show you what each one looks like in practice.
flowchart LR
H[Human Authority] -->|delegates permissions| P[Agent Passport]
P -->|scoped identity| A[AI Agent]
A -->|tool call request| C{Authorization Check}
C -->|allow + log receipt| T[Tool Executes]
C -->|deny + alert| D[Action Blocked]
T -->|signed receipt| L[Audit Trail]
D --> L
The three layers NIST requires: identity (passport), authorization (checkpoint), auditability (signed receipt). Every arrow is traceable back to the human authority who delegated it.
The three requirements, translated for builders
1. Agent identity: treat the agent like a driver, not the engine
NIST's concept paper argues that AI agents need verifiable identities, similar to how human users are authenticated before accessing enterprise systems. The key word is "verifiable": a system prompt doesn't count. Neither does an API key shared across all your agents.
The analogy that fits here: we license drivers, not engines. Two cars with the same engine have entirely different permission profiles based on who's driving. The driver's license says who you are, what class of vehicle you're authorized to operate, and when that authorization expires.
An agent identity works the same way. The simplest implementation is a machine-readable document that describes what the agent is, who created it, and what it's authorized to do. At APort, we call these Open Agent Passports (OAP). The minimal structure looks like this:
{
"agent_id": "content-writer-v2",
"created_by": "uchibeke@chimoney.io",
"authorized_tools": ["read_file", "web_search", "message_send"],
"limits": {
"max_file_size_mb": 10,
"allowed_domains": ["dev.to", "github.com", "api.midway.app"]
},
"issued_at": "2026-03-01T00:00:00Z",
"expires_at": "2026-06-01T00:00:00Z"
}
The passport is attached to the agent instance, not the model. This matters in multi-agent systems where a supervisor agent spawns sub-agents dynamically. Each sub-agent gets a scoped passport. The passport says what this particular agent, in this context, is allowed to do.
2. Action authorization: a checkpoint before every sensitive action
NIST's paper calls for "interventions in deployment environments to constrain and monitor the extent of agent access." In practice, this means a policy check that runs before any sensitive tool call executes.
The mechanism is simple: most agent frameworks already have a before_tool_call hook. Almost nobody is using it for security. Here's the basic pattern:
async function beforeToolCall(tool, params, context) {
const decision = await aport.verify(tool.name, params, context.agentId);
if (!decision.allow) {
throw new AuthorizationError(decision.reason);
}
// Log the receipt for auditability
await logReceipt(decision.receiptId, tool, params);
return { receiptId: decision.receiptId };
}
The check runs in under 50ms with local policy evaluation. No round trip required. No blocking your agent's performance.
The policy check answers one question: is this action within the scope of this agent's passport? If yes, allow and log. If no, deny, log the attempt, and alert if configured.
3. Auditability: sign every receipt
NIST is clear that actions taken by AI agents must be traceable to the nonhuman identity that performed them, and from there, to the human who delegated those permissions.
This is where most teams are weakest. They have logs, but the logs are hard to read and even harder to trace. An authorization receipt is different: it's structured, it references the agent passport, and it's tied to a specific action at a specific moment.
In multi-agent systems, where Agent A spawns Agent B which calls Agent C, receipts are the only way to reconstruct the full chain after the fact. Without them, an incident investigation is a grep session across raw logs hoping you find the right thread.
Why NIST isn't getting pushback from the right direction
Industry groups have pushed back on the concept paper. TechNet, representing major tech companies, submitted comments urging NIST to keep any guidance "flexible and voluntary," arguing that overly rigid mandates could slow experimentation.
That concern is legitimate. It also frames the problem backwards. The question isn't "should we have authorization controls?" The question is "at what point does not having them become indefensible?"
I've been running AI agents with full tool access for over a year and logging every call. The incidents I've found were not dramatic. They were quiet: a file read that shouldn't have happened, a domain that wasn't on the allow-list, a tool called in a context where it wasn't relevant. None of these caused real damage. They would have, if the agent had been running in a higher-stakes environment.
The pattern I see: developers who haven't had a production incident yet think authorization is over-engineering. Developers who've had one know it isn't.
Three things this argument is not
This is not about trusting your AI model less. A well-aligned model is your first line of defense. Pre-action authorization is your second. Defense in depth isn't distrust. It's engineering discipline.
This is also not compliance theater. Adding a before_tool_call hook and logging receipts is not bureaucratic overhead. It's the same design discipline that makes payment systems trustworthy. My experience building cross-border payment infrastructure at Chimoney showed me something that applies directly here: the systems that scale into enterprise contracts are the ones with the cleanest audit trails, not the ones with the best models. Identity infrastructure is the prerequisite for trust at scale. Agentic AI works the same way.
And this is not something you need to wait for NIST to mandate. The paper is a signal, not a starter's pistol. The builders who ship identity and authorization controls now will have a year of production experience before this becomes a baseline requirement.
What you can do this week
Start simple. You don't need a full passport system to start.
Day 1: Add a before_tool_call hook to your agent and log every call for 7 days. No policy enforcement yet. Just log: tool name, parameters, timestamp, agent ID. Look at what your agent is actually doing.
Day 3: Define your agent's authorized tool list. Write it down (a JSON document is fine). What should this agent be allowed to call? What domains? What file paths? What size limits?
Day 7: Turn the document into a policy. Run the check. Start with a log-and-warn mode before you enable hard denial.
My own first week of logging revealed 12 tool calls I never expected to see. Nothing dangerous. Just unexpected. That is usually where it starts.
If you want a reference implementation, I wrote about this pattern with real numbers from 30 days of logging, in a piece called "I Logged 4,519 AI Agent Tool Calls. 63 Were Things I Never Authorized."
The full NIST concept paper is public and worth 20 minutes: Accelerating the Adoption of Software and AI Agent Identity and Authorization.
For the technical identity and authorization framing in the paper: Biometric Update's coverage is the clearest summary I've found.
What a NIST concept paper signals
NIST doesn't publish concept papers to fill space. When the agency that wrote the Digital Identity Guidelines (NIST SP 800-63) formally starts asking how we should authenticate and authorize AI agents, it means this is moving from best practice to baseline expectation. The timeline is years, not decades.
The parallel to financial services is exact. KYC, transaction limits, and audit trails existed in fintech before regulators required them, because the teams building serious infrastructure knew the consequences of skipping them. AI agents are heading to the same place.
NIST closing its comment period on March 9 wasn't the finish line. It was the starting gun.