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

Grantex adds verifiable agent and principal credential context that merchants can validate alongside independent payment and risk controls.

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
• IETF draft-mishra-oauth-agent-grants-01 — 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.

Try It Now

The entire implementation is open source and 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.