An AI agent requests access to your payment API. Your auth server validates the OAuth token. Request approved.
But which AI system made that request? Acting on whose authority? Within what scope? If it misbehaves, who do you call?
Your API key cannot answer these questions. It was never designed to.
I wrote this because AI agents are already inside your infrastructure. They authenticate with the same API keys and OAuth tokens we have used for a decade. Nobody asks which AI made the request, on whose authority, or what happens when it goes sideways. NIST just published IR 8596 to address this. The framework is sound. Like all good standards, the implementation guidance is thin. That gap is where risk accumulates.
This is about what NIST gets right, where the protocols fall short, and what to build now.
The Human Assumption Is Broken
Every trust framework we have built assumes a human in the loop. Someone who presents credentials, responds to challenges, and faces consequences when things go wrong.
AI agents break that assumption. They authenticate once and act continuously. They spawn sub-agents and operate at machine speed across trust boundaries. The human who authorised them may be asleep, on holiday, or no longer with the company.
I have spent years building trust infrastructure in telcos, banks, and defence. The pattern is consistent. Machine-to-machine trust, privileged access, and credential compromise are where attackers focus. After they have popped your badly unpatched systems, obviously. The same vulnerabilities I saw in critical infrastructure are now present in AI systems. The difference is the attack surface scales with every agent you deploy.
What NIST Gets Right
The framework makes distinctions that matter.
Identity is not authentication
Knowing a request has valid credentials is different from knowing which specific AI system made it. An API key proves access. It does not prove identity.
Authorisation needs boundaries
Not "this key can access the API" but "this AI is authorised for these specific actions, up to this risk level, until this expiration."
Delegation chains require accountability
Every AI action should trace back to an accountable human or organisation. If you cannot answer "who authorised this AI to act?" you do not have trust. You have hope.
Trust is layered
Network authentication, application credentials, system identity, authorisation scope, behavioural monitoring. These are separate concerns. Collapsing them into a single API key leaves gaps.
Where NIST Stops Short
The framework stops at principles. No protocols. No guidance on how OAuth should evolve. Nothing concrete on credential formats, revocation at machine speed, or delegation encoding.
Most organisations will read this and default to what they know. mTLS, OAuth tokens, IP whitelisting. Standard service-to-service patterns. Not wrong. Incomplete.
I run an MCP cluster operator in Kubernetes that lets AI agents interact with infrastructure through defined tools. Namespace isolation, Vault-managed secrets, network policies. The right way to do it. And it still does not feel complete. That is what spawned this piece. The gaps are not in the implementation. They are in the protocols themselves.
The Attack Surface
Four gaps matter.
Click a threat to see the attack scenario.
What Actually Works
Treat machine identity as a first-class problem. Not an afterthought bolted onto service accounts.
API Key
Verifiable Credential
Verifiable Credentials for machines
W3C VCs that explicitly identify machine type, owning organisation, capabilities, authorisation scopes, and public key. Rate limits, allowed endpoints, API version. A relying party knows which specific machine, of what type, operated by which organisation, with what declared capabilities. Not just "valid token."
Hardware-bound keys
Attackers win through keys and authority, not broken math. TPM and Secure Enclave attestation give you cryptographic proof that the private key lives in hardware rather than on disk waiting to be exfiltrated. The ecosystem tooling is maturing. This is where it needs to go.
Tiered verification
Borrow from NIST's Identity Assurance Levels but adapt for machines. Level 0: fully automated, cryptographically verified, sub-second processing for routine operations. Level 3: human-in-the-loop approval for high-risk actions. Most machine traffic stays at L0. High-value transactions escalate. The same risk-based thinking we have applied to human identity for years.
Configurable trust policies
Relying parties define what they accept. Explicit issuer whitelists, category subscriptions to industry registries, delegated registries for enterprise control. Layered evaluation checks whitelist first, then subscriptions, then global registry. An organisation sets their risk appetite. The policy engine enforces it.
Anyone in Kubernetes will ask about SPIFFE. Fair question. SPIFFE SVIDs solve workload identity within a trust domain, and they do it well. The gap is cross-organisational. When your AI agent presents identity outside your cluster, outside your company, SPIFFE does not help. Verifiable Credentials extend workload identity across trust boundaries with the same cryptographic rigour. Complementary, not competing.
Honest Accounting
Some problems are not solved yet. Worth being direct about that.
Delegation credentials remain open
NIST distinguishes AI acting autonomously from AI acting on behalf of humans. When an AI exercises delegated authority, you need to express whose authority, within what scope, with what constraints. No standard way exists to encode that chain. The IETF GNAP working group is addressing this. Not production-ready. Right direction.
Claim-level policy is the next evolution
Current evaluation is issuer-level. Do I trust who issued this credential? The next step is claim-level. Does this credential assert the specific capabilities required for this action? On the roadmap. Not deployed.
Behavioural attestation does not exist yet
No reputation scoring, no trust degradation based on observed behaviour. A credential is valid or it is not. The monitoring infrastructure exists. Turning that into trust attestations other systems can consume is future state.
What To Do Now
Start with the baseline regardless of AI involvement. mTLS between services, short-lived tokens with explicit scopes, request signing for integrity, comprehensive logging with machine identifiers, regular credential rotation. Standard hardening. It does not solve the identity problem. It raises the floor.
Enhanced identity is where organisations with real exposure are heading. Machine identity credentials that distinguish system type and capabilities. Hardware-bound keys where possible. Issuer-level trust policies with configurable registries. Tiered verification based on action sensitivity. RFC 9396 Rich Authorisation Requests for structured authorisation objects that constrain what the agent can do, not just coarse OAuth scopes. Implementable now with existing standards. W3C VCs, DID resolution, TPM attestation. Requires investment. Does not require new protocols.
Verifiable delegation is the horizon. Delegation credentials capturing authorisation chains. Claim-level policy evaluation. Behavioural attestation with dynamic trust scoring. Cross-organisational trust federation. Standards need to mature here. The MCP ecosystem is starting to address parts of this. SEP-991 introduces URL-based client registration that could support verifiable client identity. Integration across the full stack is emerging. Not ready for production.
The Choice
AI agents are already talking to your systems. Calling APIs, processing data, making decisions. You trust them implicitly every time you accept a request with a valid token.
The question is whether that trust is warranted. And verifiable.
You can extend identity infrastructure deliberately. Verifiable credentials, explicit delegation, behavioural accountability. Or by accident, with the same API keys we have used since 2010.
The organisations building deliberately now will not need to retrofit trust later. The rest will learn the hard way.