Our Submission to NIST on AI Agent Identity and Authorization

On March 12, 2026, we submitted comments to the National Institute of Standards and Technology in response to their concept paper on Accelerating the Adoption of Software and AI Agent Identity and Authorization. The comment period closed on April 2. Here is what we proposed and why.

What NIST is asking

The NCCoE project is scoping a demonstration effort for how identity standards and best practices can be applied to AI agents. The concept paper poses six question areas: general use cases, identification, authentication, authorization, auditing and non-repudiation, and prompt injection.

The comment period invited industry participants to share real-world experience and propose approaches. The input will inform whether the NCCoE proceeds with a demonstration project and what it includes.

The gap we identified

The concept paper lists MCP, OAuth 2.0/2.1, OIDC, SPIFFE/SPIRE, SCIM, and NGAC as standards under consideration. These are strong identity-layer protocols. They answer the question: who is this agent?

But for agents operating in commerce and financial contexts, there is a second question these protocols do not address: what does this agent's wallet hold, and can I trust it to settle? Identity tells you who. It does not tell you if they can pay.

This is the cold-start trust problem — and the case for condition-based access applied to agent identity and authorization. When two agents meet for the first time, neither has behavioral history on the other. On-chain wallet state — token balances, NFT ownership, staking positions, identity credentials — is the only objective, verifiable signal available at first contact.

From our submission:

The fundamental difference between agentic architectures and traditional microservices is that agents make autonomous decisions about which counterparties to interact with. In a microservices architecture, the service graph is fixed at deployment time and authorization is configured statically. In an agentic architecture, an agent may encounter a previously unknown counterparty and must make a real-time trust decision.

What we proposed

We proposed that the NCCoE demonstration project include on-chain credential verification alongside the OAuth/OIDC/SPIFFE patterns already identified in the concept paper.

The mechanism is straightforward. An agent requests an attestation specifying up to 10 conditions — for example, wallet holds at least 1,000 USDC on Ethereum AND holds an NFT from a specific collection on Base AND has a Coinbase Verified Account attestation. InsumerAPI evaluates each condition against live on-chain state and returns a signed result: pass or fail, with per-condition detail.

The result is ECDSA P-256 signed, with the public key discoverable via a standard JWKS endpoint (RFC 7517). This is the same key discovery mechanism used by OAuth 2.0 authorization servers, meaning any system already configured to verify JWTs via JWKS can verify on-chain attestations without custom integration.

From our submission on authentication:

For the second question [authenticating claims about an agent's resources], strong authentication means: deterministic verification (the same inputs always produce the same result for a given block), cryptographic binding (ECDSA P-256 signed, modifying any field invalidates the signature), independent verifiability (any party can verify using the public key from the JWKS endpoint), and optional trustless verification via EIP-1186 Merkle storage proofs.

Why on-chain credentials fit the framework

We addressed each of the six question areas. Three points stood out as particularly relevant to what NIST is building:

Zero-trust alignment. On-chain attestations are evaluated against live blockchain state at the time of the request. They expire after 30 minutes. They are independently verifiable without calling back to the issuer. This maps directly to the zero-trust principles the concept paper emphasizes.

Non-repudiation by design. Each attestation has a unique ID, a signature covering the full result, a SHA-256 condition hash over the exact logic evaluated, and a block number anchoring it to a specific point in blockchain state. An auditor can independently verify all of this without access to the original API.

Prompt injection resistance. The attestation result is computed server-side from on-chain state, not from natural-language input. An agent cannot be prompt-injected into producing a false attestation. The verification logic is deterministic and the result is signed by a key the agent does not control.

This is not theoretical

InsumerAPI is in production. The system evaluates wallet state across 33 blockchains and returns cryptographically signed attestations used by real applications today:

• AsterPay uses InsumerAPI attestations and trust profiles for wallet verification in its payment infrastructure, with daily API calls across both endpoints.
• Revettr integrates trust profiles for multi-chain wallet verification as part of a dual-protocol approach using both x402 and MPP for agentic commerce.
• SettlementWitness uses attestations for pre- and post-transaction wallet verification in suspicious activity reporting, providing cryptographic proof of wallet state at the time of settlement.

We also maintain agent SDKs for LangChain (Python), ElizaOS (TypeScript), and OpenAI GPT, and publish an MCP server listed on the Official MCP Registry exposing all API endpoints as callable tools.

Standards interoperability

We recommended the NCCoE framework consider three additional standards alongside those already listed:

• JWKS (RFC 7517) as a unifying key discovery mechanism across both OAuth authorization servers and on-chain credential issuers.
• W3C Verifiable Credential Data Integrity 1.1, which defines a structure for ECDSA-signed credentials that aligns with the attestation format.
• Ethereum Attestation Service (EAS), an on-chain credential system deployed across multiple chains, with issuers like Coinbase (KYC verification) and Gitcoin (humanity scores) representing a growing ecosystem of identity credentials that agents can present and verifiers can check.

What happens next

The comment period closed April 2, 2026. NIST will synthesize the submissions and use them to develop a draft project description. Beginning this month, the CAISI initiative will hold listening sessions on sector-specific barriers to AI agent adoption.

If the project moves forward, the NCCoE intends to build a demonstration using commercially available technologies and publish a practice guide documenting real-world implementation approaches.

Our position is that on-chain credential verification belongs in that demonstration — not as a replacement for OAuth or SPIFFE, but as a complement that covers what those protocols cannot: verifiable claims about an agent's on-chain resources, issued in real time, expiring quickly, and checkable by anyone with the public key.

The standards that get embedded in the framework now are the standards the market will inherit. We think on-chain credentials should be one of them.