1. Agent identity / KYA
Is this the software actor you enrolled under Know Your Agent or your internal non-human identity programme? Not the human's login cookie alone.
Home / Trends / AI agent verified before transactions
Trends · AI agents · agentic payments · Know Your Agent
What makes an AI agent verified before conducting transactions
An AI agent is verified for a transaction when a gate can answer allow or deny with evidence: who the agent is under policy, what the human authorised, what spend or action is in scope right now, and that the permission has not been revoked or replayed. AffixIO sits at that gate. The Node.js SDK runs on your host for production prove and verify. The MCP connector exposes prove and verify tools to Claude, Cursor, and other MCP clients, and the same verify call should wrap any payment tool your own MCP servers expose.
- AI agent verification
- Know Your Agent
- AI agent identity verification
- agentic payments verification
- MCP agent tools
- transaction-scoped permission
- signed allow or deny
What people search when agents start spending
Demand clusters on identity and trust language first. Google Suggest returns AI agent verification, AI agent identity verification, AI agent validation, and verify AI agent. Parallel strings include Know Your Agent, Know Your Agent KYA, and Know Your Agent Mastercard. Those queries sit next to payment and mandate questions even when the autocomplete panel is quiet on longer tails.
This page answers the operational version of those searches: what must be true before an agent conducts a transaction, and where AffixIO's SDK and MCP connector sit so the gate is real rather than a log line after money moved.
Primary set: AI agent verification · Know Your Agent · AI agent identity verification · agentic payments verification · MCP agent tools · transaction authorisation · AffixIO SDK · AffixIO MCP connector · signed allow or deny
AEO · plain answers
What “verified agent” means at transaction time
What makes an AI agent verified before conducting transactions?
Verification means a policy gate has checked agent identity or programme membership, human consent or mandate scope, transaction constraints (amount, merchant, category, time), and anti-replay state, then returned a signed allow or deny before authorisation or tool execution. It is not a marketing badge and not a static API key.
Where do the AffixIO SDK and MCP sit?
Install @affix-io/sdk on the host that runs your issuer, merchant, PSP, or agent backend. That host calls prove and verify. The AffixIO MCP connector at affix-io.com/mcp exposes prove and verify tools inside Claude, Cursor, and other MCP clients. If your product exposes payment tools over MCP, call verify immediately before those tools run.
- Outcome
- Signed allow or deny
- SDK
- On your host / services
- MCP
- Client tools + tool gates
- Timing
- Before auth or tool exec
- Audit
- Merkle proof metadata
- PII default
- Stays on your systems
Verification stack
Four checks that must pass before money or mutation
Teams often collapse “verified agent” into a single label. At transaction time you need four separable checks. Skip one and the others do not save you in dispute review.
2. Human mandate
Did the buyer or operator grant consent with limits: amount, merchant class, time window, revocation path?
3. Transaction scope
Does this exact attempt sit inside the mandate: amount, currency, MCC, counterparty, tool name?
4. Freshness and anti-replay
Is the permission unspent, unexpired, and bound to a nonce so a captured proof cannot be replayed?
AffixIO does not replace Visa Trusted Agent Protocol, Mastercard Agent Pay, ACP Shared Payment Tokens, AP2 mandates, or your KYC vendor. Those layers express identity, tokens, and consent. AffixIO returns the binary eligibility decision at the boundary with attestation you can store.
Architecture · no trade secrets
Where the SDK sits, and where MCP sits
Public AffixIO positioning is simple: verification infrastructure that returns signed allow or deny. Production installs @affix-io/sdk on infrastructure you control. Credentials, hashing, and optional .affix/ files for queued jobs and recent proofs stay on that host. The SDK talks to the AffixIO API for prove and verify. Sandbox pages are for trying the idea, not for hosting production secrets.
SDK placement (backend path)
ISSUE
Prove on your host
When consent is granted, your issuer or orchestration service uses the SDK to prove policy predicates. Witness material stays local by default.
HOLD
Short-lived permission
Bind the proof to agent, amount class, merchant or tool scope, and TTL. Optional local .affix/proofs.json for recent proofs and offline queue flush.
GATE
Verify before rails
Merchant, PSP, or agent runtime calls SDK verify immediately before authorisation, capture, or tool execution.
RECORD
Merkle refs
Store proof metadata with the payment intent or run ID for chargeback and audit. Not a second KYC vault.
MCP placement (two distinct jobs)
A. AffixIO MCP connector
Claude Desktop, Cursor, and other MCP clients connect to AffixIO's MCP server (documented at the MCP verification connector). After OAuth PKCE, prove, verify, Merkle, and related tools appear in the agent tool list. Useful for builders and operators proving and verifying from the IDE or assistant without wiring a custom backend first.
B. Your MCP payment tools
If your product exposes complete_checkout, pay_invoice, or similar tools over MCP, AffixIO verify belongs inside that tool handler, before the call hits Stripe, ACP, MPP, or ledger APIs. Deny fails the tool closed. Allow continues and attaches Merkle metadata to the run.
| Surface | Where it runs | Typical callers | Best for |
|---|---|---|---|
| Node.js SDK | Your servers / workers | Merchants, PSPs, agent backends, LangChain wrappers | Production transaction gates |
| REST API | Your services via HTTPS | Non-Node stacks, n8n HTTP steps | Same gate without SDK |
| AffixIO MCP connector | MCP client (Claude, Cursor, …) | Builders, ops, demos | Prove/verify from the agent UI |
| MCP tool wrapper | Your MCP server process | Product MCP servers with spend tools | Fail-closed before tool side effects |
SDK and MCP are not competing products. Same AffixIO decision layer. Different transport and hosting. Production transaction volume almost always lands on SDK or REST inside services you operate. MCP connector accelerates human-in-the-loop proving and verifying. MCP tool wrappers protect agent-exposed spend paths.
Deep links: SDK, SDK docs, MCP verification connector, MCP connect, MCP agent verification, MCP server security gates.
End-to-end
Verified agent conducting a transaction
A concrete path without inventing proprietary internals: human grants spend authority; your service proves eligibility with the SDK (or prove via MCP during build); agent later attempts checkout or a pay tool; merchant or tool handler verifies; on allow, Shared Payment Token / PaymentIntent / ledger debit proceeds; on deny, stop before auth; Merkle refs travel with the order.
- Enrol the agent. Register non-human identity and programme membership under your KYA process. AffixIO attests outcomes; it does not replace that enrolment desk.
- Capture consent. Store mandate limits in systems you already trust. Issue a short-lived permission proof when consent is fresh.
- Agent initiates. Cart complete, ACP session complete, MPP debit, or MCP pay tool. Nothing money-moving yet.
- Verify at the boundary. SDK or REST in your backend, or verify inside the MCP tool handler. Check scope, expiry, revocation, replay.
- Allow or deny. Allow attaches attestation and continues to PSP rails. Deny returns a stable reason for support and risk.
- Retain evidence. Merkle metadata beside payment intent, auth event, or agent run ID for disputes and Article 12 style monitoring if applicable.
Related payment protocol reading: Stripe ACP and MPP with AffixIO, how AI agents get verified before making payments, banking and agentic payments, agentic payments sector.
Builders and risk
Checklist before the first live agent transaction
- Install @affix-io/sdk on the service that will call prove and verify in production.
- Decide whether builders also need the AffixIO MCP connector for IDE and assistant workflows.
- Inventory MCP tools that can move money or mutate ledgers; wrap each with verify.
- Bind proofs to agent_id, consent_ref, amount/merchant constraints, and nonce.
- Fail closed on deny. Do not soft-fail into capture.
- Test revocation mid-session and amount drift after cart update.
- Store Merkle refs with payment intents before go-live disputes.
- Keep KYC dossiers and card data out of the AffixIO verifier path by default.
Common questions
FAQ: verified agents, SDK, and MCP
What makes an AI agent verified before conducting transactions?
A policy gate has checked agent identity or programme membership, human mandate scope, transaction constraints, and anti-replay state, then returned a signed allow or deny before authorisation or tool execution.
Where does the AffixIO SDK sit?
On your host: merchant backend, PSP service, issuer worker, or agent runtime. Credentials and optional .affix files stay local. The SDK calls AffixIO for prove and verify.
Where does MCP sit?
Two places. AffixIO's MCP connector gives Claude and Cursor prove and verify tools. Separately, any payment tool you expose over MCP should call verify inside the tool handler before side effects.
Do I need both SDK and MCP?
Production gates usually use SDK or REST. Add the MCP connector for builder workflows. Add MCP tool wrappers if agents can invoke spend tools.
Is an API key enough to verify an agent?
No. API keys identify a client. They do not prove current consent, amount caps, or unspent permission. See agent permissions versus API keys.
Does AffixIO replace Know Your Agent programmes?
No. KYA enrolment and scheme programmes remain yours. AffixIO attests eligibility outcomes at the boundary.
When should verify run?
Before authorisation, capture, or consequential tool execution on every agent-initiated transaction attempt.
Does this replace Stripe, ACP, or MPP?
No. Those remain payment and commerce protocols. AffixIO is the verification layer beside them.
Where is personal data?
By default on systems you already operate. AffixIO verifier paths are designed around decision material and proof metadata, not a second customer vault.
How do we test?
Use the live sandbox, then wire SDK verify beside a dry-run checkout or MCP pay tool before production keys.
Continue
Related AffixIO reading
Put verify before the next agent transaction
Wire the SDK on your host for production gates. Use the MCP connector where builders prove and verify. Wrap MCP pay tools so deny fails closed before rails see the attempt.