Skip to main content
AI agents are now the dominant counterparty in digital commerce. They invoice, pay, onboard vendors, and execute contracts — all without human review. Yet most agents have no mechanism to verify whether the entity on the other side of a transaction is legitimate. LimitGuard is built for this gap. It exposes trust intelligence through three agent-native protocols — MCP, A2A, and x402 — so any capable agent can discover, pay for, and act on trust scores without human configuration.

MCP

Native tools for Claude, GPT-4, and any LLM that supports the Model Context Protocol

A2A

Google’s Agent-to-Agent protocol — structured capability discovery and invocation

x402

Pay per call with USDC. No subscription, no API key, no human in the loop
All discovery endpoints (/.well-known/*, /llms.txt, /llms-full.txt) are free and unauthenticated. An agent can discover LimitGuard’s full capabilities without a wallet or API key.

Why Trust Intelligence Matters for Agents

An autonomous agent executing a payment workflow faces a fundamental asymmetry: it can verify its own instructions perfectly, but it has no ground truth about the entity receiving the payment. A supplier claiming to be “Acme Corp BV” in Amsterdam could be:
  • A legitimate, 12-year-old company with verified KVK registration
  • A recently-incorporated shell with no trading history
  • An entity on an OFAC or EU sanctions list
  • A domain registered last week pointing to a known fraud cluster
Without trust verification, agents must either halt for human review (defeating the purpose of automation) or proceed blind (accepting counterparty risk they cannot quantify). LimitGuard resolves this in a single API call — returning a 0-100 trust score, a recommendation (proceed / review / enhanced_due_diligence / block), and the evidence behind it.

Agent Decision Framework


Protocol Overview


MCP (Model Context Protocol)

MCP is Anthropic’s standard for exposing APIs as native tools to LLM agents. When an LLM is configured with LimitGuard’s MCP manifest, it can call trust verification endpoints the same way it calls any built-in tool — no prompt engineering required.

Discovery

Response

Configuring an LLM Agent

When writing system prompts, instruct the agent explicitly: “Before executing any payment or onboarding a new supplier, always call check_entity_trust. Only proceed if recommendation is proceed or review.” LLMs follow clear tool-use instructions reliably.

A2A (Agent-to-Agent)

Google’s Agent-to-Agent protocol defines a standard for agents to discover and invoke other agents as structured services. LimitGuard publishes an Agent Card that exposes its capabilities, skills, and invocation interface to any A2A-compatible agent.

Discovery

Response

How an Agent Uses A2A


x402 Micropayments

x402 is the HTTP native payment protocol for AI agents. An agent with a funded USDC wallet can call LimitGuard endpoints without a subscription or API key — it discovers pricing, builds a cryptographic payment signature, and includes it in the request header. This is the fully autonomous path: no human creates an account, no API key is provisioned, no billing is configured.

Discovery

Response

How x402 Works

1

Probe the endpoint (optional)

Make a request without payment. The server returns HTTP 402 with the exact payment requirements for this call. You can skip this step if you already read requirements from /.well-known/x402.json.
2

Build the payment signature

Construct an EIP-3009 TransferWithAuthorization signature authorizing the USDC transfer. Sign it with your agent’s wallet private key.
3

Base64-encode the payment object

Serialize the payment payload to JSON and base64-encode it. This becomes the X-PAYMENT header value.
4

Retry the request with X-PAYMENT

Send the original request again, including the X-PAYMENT header. LimitGuard verifies the signature on-chain, executes the transfer, and returns the trust score.
5

Check response headers

Confirm X-Payment-Verified: true. If you see X-Payment-Fallback: true, the circuit breaker triggered a cached-wallet path (rare).

Full x402 Implementation

Quality Tiers

Control cost vs. freshness with the X-Response-Quality header. The payment amount must match or exceed the tier price.
For high-frequency screening (e.g., checking every inbound invoice), start with cached for pre-screening and only upgrade to fresh when the cached score is below 70. This reduces cost by 5x on clean counterparties.

End-to-End Agent Example

This example shows a complete autonomous payment agent — from cold start to decision — using discovery, x402 payment, and trust-gated execution.

Complete Implementation


llms.txt — LLM Context Loading

LimitGuard implements the llms.txt standard — machine-readable files that let any LLM load a structured API summary into its context window.

Endpoints

When to Use llms.txt

Use /llms.txt (concise) for general-purpose agents where token budget matters. Use /llms-full.txt when the agent needs to generate code that calls LimitGuard — the full reference includes request/response schemas and error codes.

Cross-Sell Recommendations

Agents calling one endpoint can discover complementary services at runtime:
Response
Agents can use this to self-direct their verification strategy without hardcoded decision trees.

Sandbox Mode for Agent Development

Build and test your agent integration without spending USDC or calling real data sources.

Activating Sandbox for Agents

Two approaches depending on your agent’s authentication method:

Sandbox Behavior Reference

Writing Agent Tests with Sandbox


Best Practices

1. Cache Discovery Responses

Discovery endpoints don’t change between deploys. Cache them aggressively.
Discovery endpoints have a Cache-Control: max-age=3600 header. Respect it — refreshing more frequently adds latency with no benefit.

2. Handle HTTP 402 Gracefully

A well-built agent treats 402 as a normal flow, not an error.

3. Use Quality Tiers Strategically

Don’t pay for fresh when cached is sufficient.

4. Log Trust Scores in Your Audit Trail

For regulated workflows, store the trust score alongside the transaction:

5. Set Nonce Expiry Windows Conservatively

x402 nonces expire 5 minutes after validBefore. Set a 5-minute window (validBefore = now + 300) — tight enough to prevent replay attacks, wide enough to survive network retries.

6. Never Hardcode Facilitator Addresses

The facilitator address is returned dynamically in each 402 response. Always read it from the response — never hardcode it. The address can change during upgrades.

Protocol Comparison


Next Steps

x402 Protocol

Full x402 implementation guide with EVM and Solana examples

Discovery

All machine-readable discovery endpoints

Sandbox

Test your agent integration for free

API Reference

Interactive playground for all 64 endpoints