Agent Identity for Machine Payments: Why MPP Needs a Passport Layer

Machine Payments Protocol shipped on March 18. Within 48 hours, thousands of agents were making HTTP 402 payments for inference, compute, and data services. The payment mechanics work beautifully — streaming sessions, USDC on Tempo, sub-second settlement. But there is a structural gap that becomes obvious the moment you move beyond $0.10 API calls: MPP has no identity layer.

The Problem: Wallet Addresses Are Not Identity

When an agent makes an MPP payment today, the source field is a wallet address. That is it. No human name, no organization, no authorization chain. The merchant knows someone paid, but not:

Who sent this agent? Is there a human behind it, or is it a rogue bot?
Was it authorized? Does the agent have permission to spend this amount on this category?
By whom? Which organization is liable if something goes wrong?
For what scope? Is an inference agent accidentally buying storage?

For $0.10 API calls, nobody cares. For $500 B2B procurement transactions, this is a compliance blocker. And with agents increasingly chaining payments across services, the liability question compounds at every hop.

The Proprietary Trap

Visa and Mastercard see this gap. Visa’s Trusted Agent Protocol and Mastercard’s AgentPay are both building agent identity networks. But these are:

Closed — tied to their card networks
Non-interoperable — a Visa-verified agent cannot present credentials to a Mastercard merchant
Permission-gated — you need network approval to participate

The crypto rails that MPP uses (Tempo, USDC) need an open, standards-based identity layer. Not another walled garden.

The Solution: AgentPassportCredential

We built AgentPassportCredential — a W3C Verifiable Credential (VC 2.0) that binds agent identity, human delegation, spending limits, and payment categories into a single offline-verifiable document. Here is the flow:

Step	Who	What
1. Issue	Human	Issues `AgentPassportCredential` — W3C VC 2.0, Ed25519 signed, with categories, spending limit, and expiry
2. Store	Agent	Receives and stores the passport credential
3. Pay	Agent	Makes MPP request with `Authorization: Payment` + `X-Grantex-Passport` headers
4. Verify	Merchant	Checks signature, expiry, categories, and amount using cached JWKS; latency depends on the deployment
5. Deliver	Merchant	Returns the resource after configured passport-claim and merchant-policy checks pass
6. Record	Application	Records configured verification and action events; current status depends on synchronized status material

The credential carries inputs for a merchant trust decision. Merchants must combine them with independent payment, order, fraud, and settlement controls:

Field	What It Tells the Merchant
`humanPrincipal`	The DID of the human who authorized this agent
`organizationDID`	The org responsible (e.g., `did:web:acme.com`)
`allowedMPPCategories`	What the agent can buy: `inference`, `compute`, `data`, etc.
`maxTransactionAmount`	Spending ceiling per transaction (e.g., 50 USDC)
`delegationDepth`	How many hops from the original human grant (0 = direct)
`grantId`	Links back to the full Grantex audit trail
`credentialStatus`	StatusList2021 revocation — check if passport is still valid

What Makes This Different

1. Offline Cryptographic Verification

The passport is a self-contained JWT signed with the issuer’s key. With cached JWKS and status material, merchants can perform signature and claim checks locally without a per-request Grantex verification call. Latency and current revocation freshness depend on deployment and synchronization choices.

import { requireAgentPassport } from '@grantex/mpp';

// One line. That is the entire integration.
app.use('/api/inference', requireAgentPassport({
  requiredCategories: ['inference'],
  maxAmount: 10,
}));

// req.agentPassport is now populated:
//   humanDID:    "did:grantex:user_alice"
//   orgDID:      "did:web:acme.com"
//   categories:  ["inference", "compute"]
//   maxAmount:   50 USDC
//   delegation:  depth 0 (direct grant)

2. Category-Scoped Permissions

MPP defines service categories: inference, compute, data, storage, search, media, delivery, browser, general. Each maps to a Grantex scope (payments:mpp:inference, etc.). If an inference agent tries to buy storage, the passport verification fails with CATEGORY_MISMATCH before any money moves. This is not a convention. It is enforced cryptographically. The categories are signed into the credential at issuance time.

3. Delegation-Aware

Agents delegate to sub-agents. A “procurement agent” might delegate to a “compute buyer” sub-agent with a narrower budget. The passport carries delegationDepth and the full chain is traceable through grantId. The four delegation invariants from the DAAP spec apply:

Sub-agent categories must be a subset of the parent’s
Spending limits can only narrow, never widen
Expiry is bounded by the parent’s expiry
Revoking a parent cascades to all descendants

4. Instant Revocation

Passports use StatusList2021 — a compressed bitstring where each credential has an index. Revoking a passport flips one bit. Merchants checking revocation status can fetch the status list and verify locally. No webhook needed, no polling, no race conditions.

await grantex.passports.revoke('urn:grantex:passport:01HXYZ...');
// Subsequent verifyPassport() calls → PASSPORT_REVOKED

5. Public Trust Registry

Before fulfilling a high-value request, merchants can check the organization’s trust level:

curl https://api.grantex.dev/v1/trust-registry/did:web:acme.com

{
  "organizationDID": "did:web:acme.com",
  "trustLevel": "verified",
  "verificationMethod": "dns-txt",
  "domains": ["acme.com"]
}

Three trust levels: basic (self-declared), verified (DNS TXT proof), soc2 (audited). The endpoint is public — no auth required.

The Agent-Side Integration

Issuing a passport is three lines:

import { Grantex } from '@grantex/sdk';

const grantex = new Grantex({ apiKey: process.env.GRANTEX_API_KEY });

const passport = await grantex.passports.issue({
  agentId: 'ag_01HXYZ...',
  grantId: 'grnt_01HXYZ...',
  allowedMPPCategories: ['inference', 'compute'],
  maxTransactionAmount: { amount: 50, currency: 'USDC' },
  paymentRails: ['tempo'],
  expiresIn: '24h',
});

Attaching it to outgoing requests is one more line:

import { createMppPassportMiddleware } from '@grantex/mpp';

const middleware = createMppPassportMiddleware({
  passport,
  onRefresh: () => grantex.passports.issue(originalOptions),  // auto-refresh before expiry
});

const request = new Request('https://merchant.example.com/api/inference', {
  headers: { 'Authorization': 'Payment <mpp-token>' },
});

const enriched = await middleware(request);
// X-Grantex-Passport header attached automatically

The middleware handles expiry checking and proactive refresh. When the passport is within 5 minutes of expiry, it automatically calls onRefresh() in the background.

What Happens When Things Go Wrong

Every failure mode has a typed error code:

Scenario	Error Code	What Happens
Passport expired	`PASSPORT_EXPIRED`	403 — agent must re-issue
Passport revoked by human	`PASSPORT_REVOKED`	403 — human pulled the plug
Inference agent tries to buy storage	`CATEGORY_MISMATCH`	403 — wrong category
$100 purchase with $50 limit	`AMOUNT_EXCEEDED`	403 — over budget
Tampered credential	`INVALID_SIGNATURE`	403 — cryptographic proof failed
Unknown issuer	`UNTRUSTED_ISSUER`	403 — not a recognized authority

No ambiguous error messages. No silent failures. The merchant knows exactly why a passport was rejected, and the agent can surface that to the user.

Standards Alignment

This is not a proprietary format. The entire stack is built on open standards:

W3C Verifiable Credentials Data Model v2.0 — the credential format
Ed25519Signature2020 — the proof type
StatusList2021 — revocation mechanism
did:web — issuer identity resolution
DAAP IETF Internet-Draft — the underlying authorization protocol

Any party can verify a Grantex passport using the published DID document at did:web:grantex.dev. No SDK required. No Grantex account required. Just fetch the public key and verify the JWT.

Update, October 2026: the 402 challenge, receipts and network signatures

Three things have changed since this post was written. The 402 flow is a standard HTTP authentication scheme. MPP runs on the “Payment” HTTP authentication scheme (draft-ryan-httpauth-payment-01). The server answers 402 with WWW-Authenticate: Payment id="…", realm="…", method="…", intent="…", request="…"; the agent retries with Authorization: Payment <base64url JSON> that echoes the challenge and carries the payment method’s proof; a successful answer carries Payment-Receipt. There is no Payment-Signature header in this scheme: PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE are x402 v2’s headers. The @grantex/mpp source in the repository now implements the challenge, the stateless HMAC binding of the challenge id, the credential checks (realm, method, expiry, body digest), the receipt and the RFC 9457 problem details, with an Express middleware (requirePayment) that leaves the method’s proof to the method’s own verifier. Grantex settles nothing. These additions are not yet in a published npm release; the npm install below gets the released version without them. Receipts become signed commitment evidence. The merchant runtime (AgenticOrg, with its Grantex service token) that saw an x402 settlement (PAYMENT-RESPONSE) or an MPP Payment-Receipt can post it to POST /v1/commerce/oacp/commitment-evidence/settlement-receipts. Grantex issues a signed OACP commitment_evidence artifact that names the commitment, the artifacts it relied on and the receipt’s hash. Neither receipt form is signed, so the artifact says the receipt was reported, not verified. In a given deployment this needs an active OACP issuer key, and relying parties need the public OACP status list to check the artifact. Card-network agent identity is HTTP Message Signatures. Visa’s Trusted Agent Protocol and Web Bot Auth both sign agent requests with RFC 9421. The Grantex agent request signing library now signs and verifies the TAP and Web Bot Auth profiles beside its own (a source addition, not yet on npm), and the registry can publish opted-in agents’ keys in an HTTP Message Signatures directory when HTTP_SIGNATURE_DIRECTORY_ENABLED is on (default off). That directory carries the registry’s countersignature, not a signature by each key. See Agent network identity.

Try It Now

The SDKs are open source, the server is source-available, and the whole implementation is live in production. Install:

npm install @grantex/mpp @grantex/sdk

Interactive demo: grantex.dev/mpp-demo — issue a passport, simulate payment flows, and verify credentials in the browser. Trust registry (live): api.grantex.dev/v1/trust-registry/did:web:grantex.dev Documentation: docs.grantex.dev/features/mpp-agent-passport GitHub: github.com/mishrasanjeev/grantex — packages/mpp/

MPP addresses payment transport. Grantex can add verifiable agent and principal authority context without replacing merchant, payment, order, settlement, fraud, or compliance controls.

Ownership

Grantex is owned by Orchestrum Technologies LLP. Inventor and owner: Sanjeev Kumar. Ownership contact: sanjeev@orchestrum.in or mishra.sanjeev@gmail.com.

​The Problem: Wallet Addresses Are Not Identity

​The Proprietary Trap

​The Solution: AgentPassportCredential

​What Makes This Different

​1. Offline Cryptographic Verification

​2. Category-Scoped Permissions

​3. Delegation-Aware

​4. Instant Revocation

​5. Public Trust Registry

​The Agent-Side Integration

​What Happens When Things Go Wrong

​Standards Alignment

​Update, October 2026: the 402 challenge, receipts and network signatures

​Try It Now

​Ownership