The Trust Layer for Agent-Led Commerce
Introducing the Agent Trust Certificate Framework
The Problem in 30 Seconds
An OpenAI Operator agent tries to buy office supplies from a Shopify store. The merchant's fraud system sees a headless browser session with no mouse events, sub-second page transitions, and an API-pattern checkout—and blocks it.
The merchant just rejected a legitimate $400 order. The agent operator's user never finds out why their purchase didn't go through. There's no mechanism for the agent to prove it's authorized, no way for the merchant to verify who's behind it, and no one to contact when it breaks.
Agent Trust Certificates solve this.
An ATC is a cryptographic credential that travels with the agent. It answers the three questions every merchant needs answered before accepting an agent transaction: Who authorized this agent? What is it allowed to spend? Who do I contact if something goes wrong?
What an ATC Actually Is
The Certificate Structure
An Agent Trust Certificate is a signed JSON object. Here's the full structure:
{
"version": "1.0",
"agent_id": "agt_9f8e7d6c5b4a3210",
"operator": {
"id": "op_openai",
"name": "OpenAI Operator",
"verified": true
},
"principal": {
"type": "organization",
"id": "org_acme_corp",
"name": "Acme Corp",
"contact": "procurement@acme.example.com"
},
"scope": {
"actions": ["purchase", "price_compare", "reorder"],
"categories": ["office_supplies", "electronics"],
"max_transaction": 5000,
"currency": "USD",
"daily_limit": 15000
},
"constraints": {
"valid_from": "2026-01-15T00:00:00Z",
"valid_until": "2026-07-15T00:00:00Z",
"allowed_merchants": ["*"],
"blocked_merchants": [],
"require_human_approval_above": 2500,
"geographic_restriction": "US"
},
"trace": {
"trace_id": "X-KYA-Trace-ID",
"session_id": "sess_abc123"
},
"signature": {
"algorithm": "Ed25519",
"key_id": "kya_pub_2026Q1",
"value": "base64url_encoded_signature..."
}
}Walk through the fields that matter:
agent_id + operator
Which specific agent instance is making the request, and which platform runs it. An OpenAI Operator agent gets a different ID than a Google Shopping agent, even if both serve the same principal.
principal
The human or organization that authorized the agent to act. This is who bears liability. The contact field gives merchants a way to reach the principal for dispute resolution without going through the operator.
scope
What the agent is authorized to do. This is the least-privilege boundary—an agent scoped to "office_supplies" with a $5,000 max transaction can't buy a $12,000 server rack, even if the principal's account could cover it.
constraints
Time-bounded validity, geographic restrictions, and escalation thresholds. The require_human_approval_above field lets principals set a dollar amount where the agent must pause and get explicit approval.
signature
Ed25519 digital signature over the entire certificate payload. The merchant retrieves the corresponding public key from KYA's key registry using the key_id, then verifies the signature to confirm the certificate hasn't been tampered with. If even one byte changes, verification fails.
How Verification Works
Four Steps, Sub-Second
When an agent presents an ATC at checkout, the merchant runs a four-step verification:
Agent presents ATC
The agent includes the certificate as a signed JWT in the X-KYA-Trace-ID header. This is the same trace ID format used across all KYA API interactions.
Merchant extracts public key
The merchant reads the key_id from the certificate header and fetches the corresponding Ed25519 public key from KYA's public key registry.
Merchant verifies signature
Using the public key, the merchant verifies the Ed25519 signature over the certificate payload. This proves the certificate was issued by KYA and hasn't been modified.
Merchant checks scope constraints
Is the certificate still valid (time bounds)? Is the transaction within the spending limit? Does the purchase category match allowed categories? Is the agent in an allowed geography?
async function verifyATC(certificate, transaction) {
// Step 1: Parse the certificate from the trace header
const cert = parseJWT(certificate);
// Step 2: Fetch the public key
const pubKey = await kya.getPublicKey(cert.signature.key_id);
if (!pubKey) return { status: "REJECT", reason: "unknown_key" };
// Step 3: Verify Ed25519 signature
const valid = ed25519.verify(
cert.signature.value,
cert.payload,
pubKey
);
if (!valid) return { status: "REJECT", reason: "invalid_signature" };
// Step 4: Check constraints
if (now() > cert.constraints.valid_until)
return { status: "REJECT", reason: "expired" };
if (transaction.amount > cert.scope.max_transaction)
return { status: "REJECT", reason: "exceeds_limit" };
if (!cert.scope.categories.includes(transaction.category))
return { status: "REJECT", reason: "out_of_scope" };
// Escalation check
if (transaction.amount > cert.constraints.require_human_approval_above)
return { status: "CHALLENGE", reason: "requires_human_approval" };
return { status: "ACCEPT", agent_id: cert.agent_id };
}On failure, three outcomes: REJECT (invalid cert, block the transaction), CHALLENGE (valid cert but escalation threshold hit—pause and request human approval from the principal), or ACCEPT (all checks pass, process the transaction).
Where This Fits in the Stack
ATCs vs. Payment Protocols
Visa announced TAP (Token Authentication Protocol). Mastercard launched Agent Pay. Google is building AP2. These are payment rails—they move money. ATCs are the identity layer—they answer "who is this agent and should I trust it?" before money moves.
ATCs don't compete with Visa TAP or Mastercard Agent Pay. They complete them.
| Stakeholder | Without ATCs | With ATCs | Integration Point |
|---|---|---|---|
| Merchants | Binary accept/reject. No agent context. | Verify identity + scope before payment. | Checkout middleware, fraud rule exception. |
| Visa / Mastercard | Token moves but no agent identity attached. | ATC metadata rides alongside TAP/Agent Pay token. | Pre-auth enrichment via ATC-to-token binding. |
| Agent Operators | Agents get blocked. No recourse mechanism. | Agents present certs. Merchants whitelist verified agents. | ATC issuance via KYA API + operator SDK. |
| Regulators | No audit trail. Can't attribute agent actions. | Full principal→agent→transaction chain. | Trace registry + pre-dispute resolution logs. |
What We Ship Today
Live Infrastructure
This isn't a roadmap deck. Here's what's built and deployed:
Trace ID Generation & Verification
Ed25519-signed JWT tokens via X-KYA-Trace-ID header. Generate, validate, list, and revoke trace IDs through the REST API or the CLI. Built on libsodium.
Pre-Dispute Alert System
Side-channel for merchants and operators to resolve issues before they escalate to chargebacks. Alert types: stop-loss, review, intent-query. Supports automated rules for auto-resolution.
KYA CLI
Command-line tool for developers. kya-cli trace generate, kya-cli trace validate <jwt>, kya-cli pre-dispute create. Install via npm.
Coming Next
Full ATC issuance API (certificate lifecycle management), merchant verification SDK (drop-in middleware), and ATC-to-payment-token binding for Visa TAP and Mastercard Agent Pay integration.
The documentation covers the full API surface: docs. The agent registry is live: directory.
Start Verifying Agents
Generate your first trace ID in under a minute. Talk to us about integrating ATCs into your checkout.