We’ve all been there: you build a cool AI agent, give it some tools, and suddenly realize you’ve basically handed a toddler your credit card.
As developers, we’re moving fast into the world of Agentic AI—systems that don't just chat, but actually do things. And one of the most exciting (and terrifying) things they can do is spend money.
But here’s the problem: our current payment systems were built for humans. They expect a "buy" click, a fingerprint, or a 3D Secure SMS. When an agent is running in the cloud at 3 AM, there is no human to solve a CAPTCHA. This is what we call the Human-Not-Present (HNP) crisis.
In this post, let’s break down how we can bridge this "trust gap" and build a secure layer for agentic payments.
The "Human-Not-Present" Problem
Traditional security assumes a conscious human intent. But agents operate on inferred goals. If you tell an agent to "book a flight," and it hallucinates a $5,000 first-class ticket when you meant economy, the bank has no way to know that wasn't what you wanted.
The risks are real:
- Identity Ambiguity: Is it your agent or a bot using stolen keys?
- Authorization Decay: A broad "manage travel" permission is too vague for a specific $200 hotel charge.
- Lack of Evidence: Cloud IP addresses tell a fraud engine nothing about the legitimacy of a transaction.
Enter the AP2 Protocol and VDCs
To fix this, we need Verifiable Digital Credentials (VDCs). Think of these as tamper-proof, cryptographically signed "permission slips" for your agent.
The Agent Payments Protocol (AP2) uses these VDCs to separate the what from the how:
- Checkout Mandate: Tells the merchant exactly what the agent is allowed to buy (no sneaky cart additions!).
- Payment Mandate: Authorizes the actual movement of funds without exposing your raw card details to the agent or the merchant.
This creates a "Closed" stage for transactions, once the terms are met, the authorization is locked and immutable.
Transaction-Level Auth > Session-Level Auth
We’ve spent years using JWTs for sessions, but for agents, a "trusted session" is a liability. If an agent is compromised, a long-lived session is a blank check.
Instead, we need transaction-level authentication. Protocols like KYAPay ensure that every single payment request carries its own proof of identity.
Imagine a JWT that doesn't just say "I am User A," but says:
"I am User A's agent, authorized to spend exactly $45.00 at 'CloudProvider X' for 'Compute Credits' before 5 PM today."
Defending Against "Machine-to-Machine Mayhem"
Even without hackers, agents can go rogue. A recursive loop or a model hallucination can drain a budget in seconds.
We need Deterministic Guardrails. Don't ask the LLM to "be careful with money." Hard-code the limits into a validation engine that sits between the agent and the gateway.
# A simple example of a pre-flight guardrail
def validate_agent_request(request, policy):
if request.amount > policy.max_per_transaction:
return False, "Transaction exceeds limit"
if request.category not in policy.allowed_categories:
return False, f"Category {request.category} not authorized"
return True, "Authorized"
# The agent can reason all it wants, but the code says NO.
Scoped Tokens: The Ultimate Safety Net
The golden rule: Never give your agent a raw credit card.
Instead, use Scoped Payment Tokens (like those from Stripe’s Agentic Commerce Suite). These tokens are:
- Merchant-Locked: Only works at specific stores.
- Category-Restricted: A travel agent token won't work at a casino.
- Short-Lived: They expire as soon as the task is done.
Wrapping Up
Securing agentic payments isn't about building higher walls; it's about building smarter protocols. By moving toward cryptographic non-repudiation and granular, scoped authorizations, we can let our agents roam free without worrying about a surprise $10k bill.
What are you building in the agentic space? Are you more worried about prompt injection or hallucinated spending? Let’s chat in the comments!
Top comments (0)