One Prompt Gave an AI Agent the Power to Move Money

A developer asked a coding agent for one new feature: let the support bot refund a customer's order. The edit landed, and an AI agent could now move money. The refund can't be undone, and no human approves it.

That is what AI attack surface looks like now. Your developers are building AI agents with AI coding agents, and the riskiest change can arrive in a single prompt. It doesn't show up in the CMDB, the API catalog or the SBOM. It shows up in the code, one edit at a time.

Watch the 90-second demo, then read what it means for your program.

What happened in the demo

The demo app is a simple customer support system: an orders API, an AI chat agent built with LangChain, and a knowledge base the agent answers from. A developer asks Claude Code to add one feature, a refund_payment tool for the support agent.

Surface Code AI runs automatically after every edit, inside the coding session. As soon as the refund tool lands, it flags new AI attack surface:

"The AI can now move money, the refund can't be undone, and no human approves it." (0:34)

It also recommends the fix: put a human approval gate in front of the action. The developer accepts. The coding agent wraps both refunds and cancellations in an approval gate, and Surface Code AI checks again and confirms the risk is cleared.

"Same session. No ticket. No security review weeks later." (1:04)

The whole loop, from risky edit to verified fix, happens before the code is committed.

Why your inventory misses this

Most organizations can't answer three questions about their applications: what is deployed, what each application is made of, and what risk each one carries. AI makes the second question much harder.

The refund tool in the demo is a few lines added to an agent's tool list. It creates no new endpoint, no new service and no new dependency. An outside-in inventory won't see it, and neither will a software bill of materials. But it changes what the application can do, and who can make it do it.

Surface Code AI builds an AI bill of materials from the code itself. It maps:

• LLM SDK call sites and the model gateways in front of them (LiteLLM, Portkey, OpenRouter)
• Agent frameworks such as LangChain, CrewAI and the Claude Agent SDK
• Agent tools and the permissions each one carries
• MCP servers, verified and unverified
• Vector stores and RAG pipelines
• The API endpoints that expose these components
• AI provider key names (it never reads the values)

It runs offline and makes no network calls. It is the code direction of apisec Surface, which discovers applications across code, web, gateway and runtime to give you a global view of every enterprise application.

Why an agent that can move money is a real risk

OWASP calls this Excessive Agency: an AI system that can take harmful actions because of unexpected, ambiguous or manipulated model output. It ranks third in the 2026 OWASP Top 10 for LLM Applications, up from sixth in 2025.

OWASP's guidance traces it to three causes: tools that do more than the task needs, permissions beyond what's required, and autonomy over high-impact decisions. The refund tool hit the third one. OWASP's fix is the one Surface Code AI recommended: "require a human to approve high-impact actions before they are taken."

The same idea appears in regulation. Article 14 of the EU AI Act requires that high-risk AI systems can be overseen by people, including the ability to override or reverse their output. A support agent that issues refunds may not be high-risk under the Act. Human oversight of irreversible actions is still the right default.

Catch it where the code is written

Security reviews that happen weeks after a change share a problem: by then, the developer has moved on, the context is gone, and the fix becomes a ticket in someone's backlog. Teams already in fix mode don't have the people for more tickets.

In the demo, the check ran inside the coding agent, on the edit that created the risk, while the developer still had the intent in mind. The recommendation was specific, the fix took one reply, and the re-check confirmed it. Nothing went into a backlog.

That's the practical case for putting AI attack surface checks inside the tools developers already use: the cheapest moment to fix a risky agent tool is the moment it's written.

What static analysis can't tell you

The demo ends on an honest limit:

"Static analysis shows the gate is on the path. Runtime testing proves whether it holds." (1:11)

A cleared finding means the approval gate exists on the code path. It doesn't prove an attacker can't get around it. A second code path might reach the payments API without the gate. The approval endpoint might accept a request from any authenticated user. A role might be able to approve its own refunds.

Those questions are answered against the running application. The apisec App Model builds a living model of each application, including its routes, identities, authorization and agents. apisec Exploit Testing uses that context to decide which tests to run where, runs them against the live application, and records each scenario as confirmed, cleared or blocked. After a fix, the same scenario runs again to confirm it.

Find the surface with Surface Code AI. Prove what is real with apisec.

What this means for your program

1. Inventory AI in code, not just in production. Run Surface Code AI on the repositories where agents are built, and keep the AI bill of materials current.
2. Put the check where code is written. Install it in the coding agents your developers use, so risky edits are flagged in the session that creates them.
3. Treat irreversible agent actions as high-risk by default. Moving money, deleting data and sending messages on someone's behalf need a human approval gate and the narrowest permissions that work.
4. Prove the gate at runtime before release. A gate on the code path is a claim. Test the running application to confirm it holds.
5. Report it the way the board will ask. Track how many agent tools can take high-impact actions, how many are gated, and how many gates are proven at runtime.

FAQ

What is AI attack surface in application code?

It's every capability an AI component adds to an application: the models it calls, the agents and tools it runs, the permissions those tools hold, and the MCP servers and data sources it connects to. A single new tool, like a refund function, can add attack surface without adding a new endpoint or dependency.

How do I find the AI agents and tools my developers have shipped?

Map them from the code. Surface Code AI is a free, open-source static analyzer that builds an AI bill of materials from a repository: LLM call sites, agent frameworks, tools and their permissions, MCP servers, RAG pipelines and model gateways. It runs offline, inside your coding agent or against any repo.

How should an AI agent handle irreversible actions like refunds?

Put a human approval step in front of them. OWASP's guidance for Excessive Agency is to require human approval for high-impact actions, limit each tool to the functions the task needs, and grant the narrowest permissions possible. In the demo, refunds and cancellations both went behind an approval gate.

Does static analysis prove an AI agent is safe?

No. Static analysis can show that a control, like an approval gate, sits on the code path. It can't prove the control holds when the application runs. In apisec's view, that takes runtime testing: running attack scenarios against the live application and confirming which ones succeed.

Try it

Surface Code AI is free and open source under the MIT license. Install it in Claude Code with two commands:

• pip install "apisec-ai-surface[mcp]"
• ai-surface init --claude-code

Or run it against any repository with uvx --from apisec-ai-surface ai-surface scan . (Python 3.10 or later). Get Surface Code AI on GitHub.

Want to see what an attacker could actually do with your applications? See a proven exploit against your application.