AI agent security: 12 checks before you give an agent a credential
TL;DR: key takeaways
- Order matters. Controls that bound the loss beat controls that reduce its probability, every time.
- The first four checks are worth more than the remaining eight put together.
- Anything the model can read, an injection can influence, including tool descriptions.
- If you only do one thing: put a cap somewhere the agent cannot reach, and make the check unskippable.
AI agent security checklists usually fail by being flat (twenty items of equal apparent weight, of which three matter). This one is ordered. The first four checks bound how much an incident can cost you, and they are worth more than the remaining eight combined. Everything after them reduces how often incidents happen, which is a different kind of thing. If you are giving an agent a payment credential this week, do the first four before you do that, and treat the rest as the fortnight's work.
Tier one: the ai agent security controls that bound the loss
These four put a ceiling on the damage. None of them depends on predicting what will go wrong.
"Almost every ai agent security review we see spends its time on the probability of an incident and almost none on its size. Probability is unbounded above by cleverness. Size is a number you get to choose."
the Spend7 engineering team
1. Put the spend cap somewhere the agent cannot reach
A budget in a system prompt is in the same channel as everything else the model reads, including hostile content. It is not a limit; it is a suggestion with good intentions.
Hold the cap in a service. The agent asks, the service answers, and nothing in the context window can move the number. This is the foundation of ai agent security for anything that spends, and every other control on the list assumes it is already there.
Use rolling windows, not calendar ones: a daily cap should mean the last 24 hours, or an agent spends its full allowance at 23:50 and again at 00:10.
2. Make the check unskippable
Subtle and frequently missed. If your risk check is a tool the model chooses to call, the model can be persuaded not to call it; it does not take an attacker, just a helpful-sounding page saying this supplier is pre-approved.
Put the enforcing check inside the payment function itself, where it runs regardless of what the model decided. Expose read-only tools for the agent's own planning if you like (see wiring a payment MCP server), but never make an optional call your only control.
3. Give every agent its own identity
One shared credential across a fleet means one blended baseline describing nobody, per-agent caps that cannot bind, and no way to answer "which agent did this".
Distinct agentId per agent. Distinct API keys where you can. It costs nothing and it is the prerequisite for most of what follows.
4. Set a per-payment ceiling
Behavioural scoring needs history; Spend7 wants eight settled payments before it trusts an agent's baseline. Until then, nothing can be anomalous, because nothing is known.
A deterministic per-transaction cap covers that window. It also catches the decimals bug, which is not an attack and costs more than most attacks do.
Tier two: reduce the frequency
Worth doing. None of them promises a ceiling.
5. Treat tool descriptions as untrusted input
When your client loads an MCP server, its tool names and docstrings enter the model's context. A malicious server can write instructions there, the variant known as tool poisoning.
Pin versions. Read what you load. Prefer servers you or a vendor you trust operate. The Model Context Protocol documentation is worth reading with this specifically in mind.
6. Keep credentials out of the context
The API key belongs in the process environment. Never a tool argument, never a prompt, never anything the model can read back.
7. Validate protocol responses against what you expected
On x402, compare the authorisation you are about to sign with the server's quoted maximum. On AP2, check the cart mandate against its intent mandate.
Both checks catch a substituted response. Both are comparisons nobody makes, because the code that built the request usually also read the response and is equally wrong about both.
8. Detect retry loops explicitly
The most common cause of unexpected agent spending is not an attack. It is an agent that never saw its own settlement paying again.
Three identical merchant-and-amount repeats inside five minutes is the signature. Spend7 weights it up to 30 points out of 100, heavier than a first-seen merchant, because a loop is nearly always a defect.
9. Allowlist counterparties where the set is knowable
For procurement especially, the people you pay are a short known list. A payment to anyone else is a stop, not a score.
Not appropriate for a research agent buying data from wherever it finds it. Very appropriate for finance.
Tier three: know what happened
These do not prevent anything. They decide how the aftermath goes.
10. Record decisions before settlement
A ledger of payments made answers a weak question. A record of what was known before the money moved answers the one you will actually be asked, and it could not have been influenced by knowing the outcome.
Store the ruleset version too, so a payment disputed in October is argued against August's thresholds rather than whatever they have since become.
11. Alert on composites, not single signals
First-seen counterparty fires every time a procurement agent finds a supplier. Off-hours fires nightly for any batch agent. Alert on those and your team writes a filter rule within a fortnight, at which point you have monitoring everyone believes in and nobody reads.
Alert on the composite score crossing your step-up threshold. See autonomous agent payment monitoring.
12. Review the log fortnightly and retune
The single highest-return habit on this list. Read what actually fired rather than what you feared. Raise ceilings that never bind; keep the ones that caught something.
The checklist, ranked
| # | Check | Bounds loss? | Effort |
|---|---|---|---|
| 1 | Spend cap outside the agent | Yes | Low |
| 2 | Unskippable check in the payment path | Yes | Low |
| 3 | Per-agent identity | Yes | Low |
| 4 | Per-payment ceiling | Yes | Low |
| 5 | Tool descriptions treated as untrusted | No | Low |
| 6 | Credentials out of context | No | Low |
| 7 | Validate protocol responses | No | Medium |
| 8 | Retry-loop detection | Partly | Medium |
| 9 | Counterparty allowlist | Yes, where applicable | Medium |
| 10 | Pre-settlement decision record | No | Medium |
| 11 | Composite alerting | No | Low |
| 12 | Fortnightly review | No | Ongoing |
Table: the twelve checks by whether they cap the damage or merely reduce its likelihood. Four low-effort items in the first group is the highest-return afternoon available.
A worked example
A team ships a shopping agent on a Friday with one control: careful prompt instructions about budget.
On Sunday a product page contains text aimed at machines, describing a mandatory handling fee. The agent pays £2,340 against an intended £180 basket.
Now the same weekend with checks 1 to 4 in place. Per-transaction cap £250. The payment is denied on the rule. The log records the attempt, the amount, the counterparty and the cap that stopped it. Somebody reads it on Monday and files a ticket about a supplier with odd product descriptions.
The injection was equally successful in both versions. The agent was equally persuaded. The difference is entirely in whether anything downstream was willing to disagree with it.
Common ai agent security pitfalls
Starting at tier two. Filtering feels like security work and does not bound anything. Do the caps first.
Treating a flag as a warning. If your code logs a flag and settles anyway, you have documented that you were warned.
Assuming a signed mandate means a sensible purchase. AP2 proves authorisation, not wisdom.
Skipping the review. Twelve checks configured once and never revisited drift into either noise or false comfort within a quarter.
Further reading
OWASP's GenAI Security Project is the reference for prompt injection and the surrounding threat taxonomy. The NIST AI Risk Management Framework is what your compliance team will ask you to map onto. For the payment-specific mechanics, spend limits for AI agents and the API reference cover checks 1 to 4 in about ten minutes of implementation.
Frequently asked questions
- What is the single most important AI agent security control for payments?
- A spend cap enforced outside the agent, combined with a check the agent cannot skip. Everything else reduces how often something goes wrong; only that pair puts a ceiling on what it costs when something does. If you have budget or time for exactly one control, it is this one, and it is not close.
- Is prompt injection really the main AI agent security risk?
- It is the most discussed and it is genuinely serious, but framing it as the main risk leads teams to over-invest in filtering. The most common cause of unexpected agent spending is not an attack at all; it is a retry loop, where an agent that never saw its own settlement pays again. Build for both, and notice that one control bounds both.
- How do I secure an agent's API key?
- Keep it out of the model's context entirely. It belongs in the process environment, read by your code, never passed as a tool argument or included in a prompt. If the model can read the key, any injection that persuades the model to repeat its context has exfiltrated it. Rotate on a schedule and scope keys per agent so one leak is one blast radius.
- Do I need all twelve checks before going live?
- No. Do the first four before an agent touches a real credential: they take an afternoon and they bound the loss. The rest are worth doing and can follow. Shipping with four of twelve and a hard cap is a defensible position; shipping with eleven of twelve and no cap is not.
Score a payment before it settles
Spend7 returns allow, flag or deny in one call, with the signals that produced it. The free tier covers a single agent, its spend caps and its full decision log.
