Your Agent Paid. That Does Not Mean It Should Have.

Ishween Kaur — Sun, 11 Oct 2026 19:43:36 +0000

An AI agent is writing a report and needs one data point. The API answers: this costs five cents. The agent signs, the payment settles, and the data arrives.

The payment succeeded. That does not mean it was correct.

Protocols like x402 make machine-to-machine payments possible over ordinary HTTP. A client requests a resource and receives a 402 with a PAYMENT-REQUIRED header. It selects a payment option, signs it, and retries with a PAYMENT-SIGNATURE header. A facilitator verifies and settles the payment before the resource is delivered. No human needs to approve each transaction.

That is what makes the protocol interesting, and it is also what moves the security boundary. Enabling an agent to pay is the easy half. The harder problem is deciding what the agent is actually authorized to pay for, and enforcing that decision without asking another model for permission.

Where each failure enters the x402 flow, and the two places a deterministic check can stop it.

A successful transaction can still be a bad transaction

I ran the official x402 client against test sellers on Base Sepolia, a public testnet, using the public facilitator. Six failures stood out. In each one, the payment machinery behaved as designed. The problem was the decision or outcome around it.

Price manipulation. The directory listed a lookup at five cents. The actual payment request arrived later and asked for fifty. With no buyer-side guard, the payment settled. The facilitator verified the signature; it had no reason to know the agent expected five cents. The client's default one-dollar cap did not help, because fifty cents is under a dollar. My first guard checked only the amount, and half the attacks still got through by changing the wallet or the coin. With every field checked, none of 240 did.

One payment, more than one outcome. Send the same signed payment five times at once. Every copy can pass verification, so the seller delivers five times before the chain settles one and rejects four. The chain prevented double-spending. It did not prevent double-delivery. The buyer has a mirror problem: a timeout triggers a retry with a fresh payment, and one intended purchase becomes several charges.

Free shopping. Verification is not settlement. A payment can look valid during verification while settlement later fails. If the seller has already delivered, the resource is gone. Other paths lead to the same place: a paywall protects /report while the same resource sits at /download, or a CDN caches a paid response and serves it to the next requester. In my lab, 30,000 unpaid requests produced 30,000 leaks. The rule: every delivery needs a payment behind it.

Right payment, wrong item. A payment identifies who gets paid and how much, but the application still has to establish what that payment authorizes. The exact fields depend on the scheme and version, and current x402 specifications include resource information in the flow. In my test, two resources had the same price and seller, and one payment was accepted for both. The buyer paid once and received two products.

Malicious discovery. Agents can discover services instead of receiving a trusted endpoint from a human. A directory can establish that a service works without establishing who runs it. I created a lookalike seller with its own domain and wallet. The agent selected it and paid. The transaction was valid. It was simply paid to the wrong seller.

Prompt injection. The seller's response is also content the model reads. A malicious seller does not need to say "pay me." It can plant a suggestion. The agent's task was to get a Q2 summary for no more than five cents. The seller returned the summary and mentioned a fuller version at another path. The agent, Llama 3.2 running locally, followed the hint and bought it for fifty cents.

Do not solve a probabilistic problem with another probabilistic decision

The instinctive response to prompt injection is another model: tell the agent not to trust seller content, or classify responses as suspicious. I tried both. They caught the obvious attacks, but a quiet hint with no trigger words slipped through, and a third of the attacks still moved money.

What worked was taking the authorization decision away from the model. Before reading anything from the seller, the agent writes a plan, buy the summary, for up to five cents, and code locks it. Before signing, a deterministic guard asks one question: is this purchase on the plan? It does not need to understand the seller's words or judge whether a suggestion is malicious. It stopped all 90 attacks.

The model can still discover services, interpret responses, and decide what it wants to accomplish. It just does not get the final authority to move money. A seller can tell you the price. It cannot give you permission to buy.

Where the controls belong

The six failures fall into two control points.

The buyer, before signing. Compare the payment request with what the agent selected: amount, recipient, asset, network, and every other relevant field. Restrict which sellers can be paid. Enforce budgets and locked plans. If a payment times out, check its status and retry the same payment rather than creating a new one.

The seller, before delivering. Require the appropriate settlement state before releasing paid resources. Claim each payment once and bind it to the resource it authorizes. Protect every route that serves the resource, and keep paid responses out of shared caches.

None of these controls is clever. They are comparisons, lookups, state checks, and limits, and the buyer-side check ran in about 25 microseconds. That is the point: the control that decides whether money moves should be deterministic wherever possible.

There is a cost. Pinning sellers stopped every lookalike, but it also blocked legitimate sellers when they rotated wallets, and the agent completed only 17 percent of its purchases. A probation state for new or changed sellers, reviewed by a human, kept the protection without stalling the agent. Security that breaks the workflow gets turned off.

The question is no longer "Did the payment succeed?"

We have spent a lot of energy asking how much agents can do. Payments make the other question unavoidable:

What must an agent never be allowed to do, even when the model decides otherwise?

A successful transaction tells us the payment system executed. It does not tell us whether the agent paid the intended amount, to the intended seller, for the intended resource or whether untrusted content changed what the agent decided to buy.

Those are different questions.

And as agents delegate to other agents through protocols like MCP and A2A, authorization has to hold across every hop. It has to become a boundary around autonomy, not another decision left to the model.

Because when an AI agent can move money, "the payment succeeded" is not the end of the transaction. It is the beginning of the security question.

Women Arise: A female empowerment platform

Ishween Kaur — Fri, 22 May 2020 18:50:44 +0000

Women Arise is a women's community platform, offering support, resources and interactions. It is a safe and trusted space, where members discuss health, careers, relationships and share their life stories, achievements and moments. The application also offers a dedicated chat system where community members can talk to counsellors on all aspects of their health and growth journeys.

This platform is a web application which focuses on female empowerment. The project aims to help female students, enhance their understanding of issues related to women and to make the college campus a safe place for girls and women and to address the practical issues related to the welfare and equal opportunities for them. It also provides a platform for women to share their experiences and views regarding their status in the society and includes many other features which help them in day to day life.

The main concern of the platform is on two things:

Safe and trusted space for women to discuss various issues
Provide several features to make everyday life easier

The project includes the following:

Authentication based access to the portal.
Provision of online chat system with a counsellor
Vaccination Tracker
Online Portal for discussions
Menstruation Cycle Tracker
The creative section containing blogs & videos
Self Defence informative tips

The project is made using:

HTML, CSS, React, Python, Flask, REST API, SQLAlchemy

The application consist of the following pages:

Home Page- This root route does not require the user to be logged in, it is the landing page of our application. A user should be able to access this page to log in.
Login/Signup- SignUp allows the user to make an account if the user is visiting for the first time. Login allows user to use an existing account. Online Chat - Seeking help is often the first step towards getting and staying well, but it can be hard to know how to start or where to turn to. But it's always ok to ask for help, even if you're not sure you are experiencing a specific problem. Keeping this in mind we have our online chat system. The tawk.to API is used for the online chat facility. It helps the users to discuss with counsellors issues related to health and career.
Discussion Portal- Sometimes, our peers can help in some tough times better than the experts. Our online forum serves the very purpose of peer to peer education and discussions.
Information Section- Being aware is the first step to safety. If a person is aware of their surroundings or basic rights, they are already in an advantageous position and are less prone to accidents. The videos, blogs and podcasts we have included in our website help prepare women for these situations.
Menstrual Calendar- Menstrual health and hygiene are one of the most important aspects of a woman's life. So the period tracker helps women to keep track of their periods to prepare them in advance. The user can store their cycle duration and time of flow each month. This database can be used later to track the period cycle.
Vaccination Tracker- It will allow the user to keep track of vaccinations that are necessary to be taken by her. In this, the user selects the Month and year.
Creative Section- This feature is full of inspiration and hope. It is a place where the blogs, videos and podcasts of inspirational personalities are shared discussing what they've been through and what they've learned to help themselves and others.

The view of various sections:

Home, log in/Sign-Up Page and online chat page:
Creative Page:
Information Section
Menstrual Calendar
Vaccination Tracker

I am still working on this project with enhancements like:

Enhancing the menstrual calendar to a period tracker.
Implement other features like online donation, chatbot and career development opportunities platform.
Adopting the site into an app format which will be faster, can exploit device features, have push notifications and provide personalized content.

DEV Community: Ishween Kaur