InsumerAPI's attestation_url Pattern
Is Now Part of KCP RFC-0004

The Knowledge Context Protocol (KCP) is an emerging standard for how AI agents discover, access, and trust structured knowledge. RFC-0004 defines the trust, provenance, and compliance layer. We contributed the attestation_url pattern, which lets any KCP manifest require credential verification before granting agent access. The pattern was accepted and merged into the spec, and InsumerAPI is the first production implementation.

The problem: allowlists do not scale

Before attestation_url, the only way a KCP manifest could restrict agent access was through trusted_providers, a static list of OIDC provider domains. This works for enterprise environments where you control which agents exist. It breaks at ecosystem scale.

Maintaining an allowlist means every new agent provider needs to be added manually. If an agent is legitimate but built by an unknown provider, it gets rejected. If a provider goes offline or rebrands, the list goes stale. The model assumes trust is about who built the agent, not what the agent can prove about itself.

The question we raised: what if trust were a function of what the agent holds, not who built it?

The contribution: attestation_url

We proposed two new fields for the agent_requirements block in KCP manifests:

• attestation_url is an HTTPS endpoint that verifies agent credentials. The agent calls this URL, presents its wallet or identity token, and receives a signed attestation response indicating whether the credential check passed.
• attestation_jwks is a JWKS (JSON Web Key Set) endpoint for validating the signatures on attestation responses. This lets any party independently verify that the attestation is authentic.

The schema in RFC-0004 now looks like this:

trust:
  agent_requirements:
    require_attestation: true
    trusted_providers: ["internal-agents.acme.com"]
    attestation_url: "https://example.com/v1/attest"
    attestation_jwks: "https://example.com/.well-known/jwks.json"

Satisfying either trusted_providers or attestation_url is sufficient. They compose with OR logic. Enterprise teams can keep their OIDC-based allowlists. Crypto-native agents can prove credentials on-chain. Both paths coexist in the same manifest.

Why mechanism-agnostic matters

KCP is a static YAML format. It describes knowledge manifests, not runtime infrastructure. The spec intentionally does not prescribe how the attestation endpoint works. Whether the endpoint verifies on-chain token holdings, W3C Verifiable Credentials, OIDC claims, or SPIFFE assertions is entirely outside the spec. The pattern is also compatible with MCP server integrations for AI agent protocols.

This was a deliberate design choice. The KCP maintainer put it clearly: "The manifest describes what is needed, not how to verify it."

For publishers, this means you declare your trust requirements once and support any verification mechanism that can serve an HTTPS endpoint. For agent developers, this means you can use whichever credential system your ecosystem already relies on.

InsumerAPI as reference implementation

InsumerAPI implements the attestation_url pattern in production today. A KCP manifest pointing to InsumerAPI looks like this:

trust:
  agent_requirements:
    require_attestation: true
    attestation_url: "https://api.insumermodel.com/v1/attest"
    attestation_jwks: "https://insumermodel.com/.well-known/jwks.json"

When an agent encounters this manifest, it calls the attestation endpoint with its wallet address and the conditions the publisher requires (token holdings, NFT ownership, EAS attestations, Farcaster identity). The response is ECDSA P-256 signed, with the key discoverable via the JWKS endpoint.

The verification properties that map directly to what RFC-0004 requires:

• Signed responses. Every attestation carries an ECDSA P-256 signature, verifiable against the public key at attestation_jwks.
• Boolean results. The endpoint returns whether conditions were met, never raw holdings or transaction history. This satisfies the privacy requirements for knowledge access control.
• Multi-chain coverage. 30 EVM chains plus Solana and XRP Ledger. A single attestation call can check conditions across Ethereum, Base, Optimism, Arbitrum, and others simultaneously.
• Time-bounded. Attestations include timestamps, block context, and expiry. Stale attestations are rejected.

What this means for the ecosystem

KCP is still early. The spec is at v0.3, and the trust layer was deferred from the core release into a dedicated RFC. But the direction is clear: AI agents accessing structured knowledge will need to prove credentials, and the infrastructure for that proof is being standardized now.

The attestation_url pattern is intentionally simple. One URL. One JWKS endpoint. OR logic with existing allowlists. No new protocols to adopt. Any verification service that can serve HTTPS and sign responses with a discoverable key fits the model. The multi-attestation format extends this further by composing results from multiple issuers.

InsumerAPI happens to be the first service that does this, with on-chain credential verification across 33 chains. But the pattern is open. As KCP adoption grows, any attestation provider can implement the same interface.

The full RFC is available on GitHub: RFC-0004: Trust, Provenance, and Compliance.

To see the attestation endpoint in action, try the live XRPL verification demo, explore the AI Agent Verification API overview, or review the full OpenAPI 3.1 specification.