Payment details belong on a secure checkout page or in a one-time payment token, never in a chat log. JENNi's agent tools don't accept card numbers at all.
That's the core of AI agent payment security, and it's simpler than it sounds. If a card number never enters the conversation, it can't leak from the conversation.
Where chat logs end up
A chat is not a vault. Messages get stored for history. They get sent to model providers. They show up in debug traces, analytics, support tools and exports. Developers copy them into bug reports.
Each of those is a place a card number would travel to, usually without anyone deciding it should. A shopper who types a number into a chat has no idea how many copies that creates.
Agents make this worse in one way. An agent that's good at helping will happily ask for whatever it thinks it needs. If the tool accepts a card number, the agent will eventually be tempted to collect one.
Two safe paths
There are two ways to pay that keep the number out of the conversation.
The hosted checkout page. The agent calls start_checkout and gets back a checkout_url. The shopper opens it, reviews delivery, tax and total, and pays on that secure page. The page re-verifies current price and availability. start_checkout creates no order and no charge by itself.
A one-time payment token. For checkout inside the chat, the flow is create_checkout, then update_checkout, then complete_checkout. Nothing is charged until complete_checkout, and that runs only after the shopper approves the total. Payment is a one-time shared payment token that starts with spt_. It's created for this one purchase, outside the conversation. The agent just passes it along.
In both cases the agent never holds anything reusable. A hosted page keeps the number on the page. A one-time token works for one purchase and isn't a card number.
AI agent payment security: refusing card numbers in code
Telling an agent "don't ask for card numbers" in a prompt is a request. Prompts can be ignored, overridden or injected around.
So JENNi refuses card numbers at the tool level. Card fields are rejected in code. If an agent tries to send one, the call fails. There's no setting that turns it off and no instruction that gets around it.
That matters because it doesn't depend on every agent builder getting every prompt right. The safe behavior is the only behavior the tool allows.
What this means for builders and shoppers
If you build agents, the benefit is less to worry about. You don't need to store, mask or scrub payment details, because your agent never receives any. Our tools never put them in your logs, traces or transcripts. You can choose the flow that suits your product: send the user to the hosted page, or complete in chat with a token.
If you're a shopper, the benefit is trust you can check. You see the total before anything is charged. Checkout refuses stale prices. Nothing is charged until you approve the final total. And you never have to type a card number into a conversation to buy something.
Because JENNi is the seller on these orders, you also know who to come to if there's an issue with what you bought.
A rule you can test
You can check any agent shopping setup with one question: at what point does a card number appear in the conversation? The right answer is never. If the answer is "when the user types it in," the design is asking users to take a risk it could remove. Hosted pages and one-time tokens exist so that nobody has to take it.
This also helps teams that never meant to handle payments. Compliance questions get shorter when the honest answer is that the agent has no access to payment details. The tools never put payment details in the chat.
Shoppers can use the same test. If a chat ever asks you to type a card number, stop and look for a checkout link instead.
Build on it
If you're building a shopping agent, connect to https://shop.jennipro.com/mcp and use start_checkout for the simplest safe handoff. The card number was never supposed to be in the chat. Now it never has to be.