AI Agents Can't Just Call Functions Anymore: The New Attack Surface Is Tool Invocation

AI agents no longer just chat. They read files, send email, create calendar events, and — increasingly — move money. Every one of those actions happens through a tool call: a function invocation that turns a model's intent into a real-world side effect.

Here is the uncomfortable part. When an agent calls a tool, there is usually no way to verify who authorized the call, why it was made, and whether the response that came back was tampered with. The model produces text; the tool produces consequences. Between the two, there is almost no auditable, tamper-evident evidence chain.

The MCP ecosystem is expanding the attack surface

The Model Context Protocol (MCP) was designed to standardize how agents connect to external tools. It succeeded — and that success is now the attack surface. ModelScope's MCP marketplace lists roughly 1,500 services (source: ModelScope MCP Square, modelscope.cn/mcp). Alipay has shipped an AI payment MCP that lets agents create, query, and refund transactions (source: Alipay Open Platform AI payment MCP launch), turning "agent-driven payments" — an agent operating real money — into a platform capability rather than a demo.

The stakes moved. When a misbehaving agent can trigger a real transaction, an un-audited tool call stops being a quality issue and becomes a financial control failure.

Why tool invocation needs governance more than model output

Model output is comparatively cheap to govern: a bad sentence is a bad sentence, visible in the transcript. A tool call is different. It is an action whose consequences outlive the conversation. Prompt injection can induce a model to invoke a sensitive tool — reading a private file, sending an email, issuing a payment. The failure materializes at the invocation boundary, not in the generated text. And the invocation itself typically carries no verifiable evidence of authorization: no record of who approved it, on what basis, and whether the tool's response was altered along the way. This is why the evidence leg of agent governance has to live outside the model — an independent record of intent and effect that the model itself cannot rewrite.

The evidence layer: CCS

That gap is what Correctover's CCS addresses. CCS is a 7-dimension runtime verification framework for AI agent systems (source: "CCS: A 7-Dimension Runtime Verification Framework for AI Agent Systems", Zenodo DOI 10.5281/zenodo.21783723). It attaches a tamper-evident receipt to every tool invocation. The receipt carries multiple hashes — request_hash, response_hash, runtime_context_hash, params_hash, and config_hash — so any change to the request, the response, the runtime context, the parameters, or the configuration becomes detectable after the fact (source: IETF draft-correctover-ccs-02). The framework draws an Action Evidence Boundary (AEB) between model reasoning and real-world action: the point where intent becomes side effect is precisely where evidence gets captured (source: IETF draft-correctover-ccs-02, https://www.ietf.org/archive/id/draft-correctover-ccs-02.txt).

Three properties matter:

• Tamper-evident. If any part of an invocation is modified — by an attacker, a compromised transport, or a buggy agent framework — the receipt breaks. You can prove a call happened exactly as recorded.
• Auditable. Every invocation yields a verifiable record answering the three questions: who authorized, why, and was the response intact.
• Bindable. CCS composes a chain: CCS → exact material-action match → AEC evaluation → Gate authorization → atomic reservation → one-time invoke → Outcome Binding. Each invocation is bound to a one-time, atomically reserved action whose outcome is recorded. A tool call cannot be replayed, double-executed, or severed from its result.

The cost of this evidence layer is small. CCS v1.0 internal benchmarking measured a P50 of under 10 microseconds and a P99 of under 25 microseconds across 50,000 iterations (source: Correctover internal benchmark, CCS v1.0). And the verification is not purely theoretical: a third party independently ran CCS's tool-invocation verification through both ALLOW and DENY authorization paths over a Unix socket, and both passed (source: independent third-party verification).

From vulnerability research to a standard

The framework is grounded in findings rather than hypotheticals. Correctover maintains 24 CCS vulnerability detection rules (source: Correctover bounty_rules.py) that produced more than 1,730 empirical vulnerability findings during CCS v4.2 bounty hunting (source: Correctover CCS v4.2 bounty hunting measurement). The research base includes 80,000 production API traces, 20,000 of which are publicly verified in the Correctover standards repository on GitHub (source: Correctover/standards).

That research feeds directly into standard making. Draft-correctover-ccs-02 was published to the IETF archive on 2026-08-10 as an 87,348-byte document (source: IETF archive, https://www.ietf.org/archive/id/draft-correctover-ccs-02.txt), and the framework is independently citable via the Zenodo record at https://doi.org/10.5281/zenodo.21783723.

The takeaway

The MCP ecosystem is growing, and so is the surface for tool-call abuse. The models will keep improving; the evidence problem will not solve itself. As agents start touching real money through payment MCPs, a tamper-evident, auditable, bindable evidence layer for tool invocation stops being a research nicety and becomes the control that keeps an agent's intent honest.

Correctover's bet is that safe agents run on evidence: 24 detection rules, 1,730+ findings, 80,000 traces, and an IETF draft that turns those lessons into a standard. The question for the industry is no longer whether agents will call tools. It is whether anyone can prove they did the right thing when they did.

---

This article is for informational purposes. Vulnerability findings are from responsible disclosure programs. Benchmark data from Correctover internal testing.