AI Agent Security Happens at the Tool Call

At what point does a team treating AI security as plumbing, meaning nobody wants to investigate, debug, or test it because that would slow the work down, fail? At the tool call.

A dangerous question that must be answered at every tool call: who is acting, which resource is canonical, what grant applies, which capability is being invoked, where the output can flow next, and what receipt exists if the runtime says no.

Connectivity to such resources is becoming easier to set up. The recent MCP SDK betas for the 2026-07-28 spec release candidate make that point plainly. So security needs to move from the setup of connection to a resource to control of execution within that resource.

The HCP paper, From Tool Connection to Execution Control, first defines eight runtime invariants that MCP-style systems need to satisfy: metadata non-authority, grant-backed approval, canonical resources, principal binding, scoped capability invocation, source-and-target data-flow authorization, deny-path audit, and explicit protocol state. For a long time these read like abstract requirements. In reality each of these is the minimum viable security invariant for an action that an agent is performing by updating CRM records, creating a customer, creating a sales process, or reporting on data in CRM. The runtime has to resolve the canonical resource, bind the principal to a grant, invoke only the scoped capability, authorize data flow, and make every denial auditable.

The approval prompt fires too early

A consent prompt tells one thing: did a human approve of this action or not. But approval of a proposed action, meaning a model asking to do something with the agent, and approval of an action after resources, policy, and tool state have resolved are two different things.

In reality, tools are not isolated containers to which an agent may make a single call. Rather, agents discover tools, read the tools’ metadata, copy data from one tool’s output to another’s input, run through loops of previously learned actions, re-run previously successful code with slightly modified parameters, and pipe the output of one tool to the input of another. As such, the place to put governance on an agent is before it makes a tool call, which is where we wrote about governance before the tool call, and after the tool call has been approved, which is where MCP security starts after tool approval. And that is narrower than it sounds, because after approval has been given to a call, the runtime is now responsible for governing the execution of that call, which is to bind the call to the particular principal, grant, resources, and capabilities that had been approved in the dialog that prompted the approval in the first place.

Now on to the HCP benchmark. The naive baseline for an MCP-like architecture allows all ten attacks to be modeled, the practice-informed mitigation strategy allows six, and the HCP benchmark blocks all ten attacks while providing complete audit evidence for the controlled benchmark in the paper. The paper itself is not something to run as a product tomorrow, but it gives a practical perspective on what prompts, metadata warnings, and approval dialogs are missing when the runtime does not own the execution objects for the calls that the agent makes.

Tool metadata cannot carry authority

Tool metadata is descriptive metadata. The model uses the tool’s metadata to choose an action. But the tool’s metadata is not authoritative for that action.

It is boring to think about tool metadata only in terms of setting up the action for the model to execute. But what if the tool’s metadata contained instructions for the model? What if a resource identifier that was provided as friendly names to the user were to map to different provider objects in the runtime? The runtime has to go ask the provider for the canonical resource for that resource identifier, and then compare that against the grants for that principal for that capability that was requested for that action. That is the set of runtime invariants for MCP-type systems as defined in the HCP paper.

Finally the MCP integration pattern transitions to the security model phase. An updateRecord CRM tool is not just another tool, even if there is already a tool with that name in the MCP workspace. It is a write tool for customer data, sales processes, reporting, and permissions. Therefore, integration of such a tool into MCP infrastructure is runtime work, which is why CRM integration becomes runtime work. Exactly the same work a user would do by pressing Save in a system of record. The only difference is that instead of a human, it is a model-guided loop, running through an integration layer.

So the simple way to look at this is that the runtime must reject the call if the following conditions are not met: the principal is missing, the grant is not found, the provider cannot canonicalize the resource, the capability is outside the scope of the grant, or the approval was for a different resolved object. Put this in a policy broker. And write down the reasons for denial.

Output handles are part of the security model

The scariest tool call is rarely the first one. It is the second one, after the agent has learned something.

When modeled data is used as input for other tools, the data can be treated as handles with owners, data classes, and checks on downstream pipes. The HCP paper investigates modes in which such data can be used, including search results, document excerpts, transcript snippets, ticket bodies, and rows in databases. Kept inside the runtime, the data can stay scoped to particular actors and capabilities instead of becoming free floating text that the agent can hand to other tools.

I’d like to provide an example of how Anthropic implemented code execution with MCP. In the example, Anthropic created a direct MCP loop between pulling a transcript from a Google Drive account and copying that transcript to update a record in a user’s Salesforce account. This would normally take 150,000 tokens, but by putting the intermediate results in the execution environment, Anthropic was able to reduce the required tokens to 2,000 tokens. Great for them, and it highlights the added security obligations of code execution.

But, if we keep the transcript in the runtime, we can then check things like: can this principal read this? Can this capability write this to Salesforce? Can this output flow to email, Slack, or external webhooks? Should the next call in the workflow see the raw text, a filtered projection of the text, or nothing at all? These are the kinds of things that belong inside AI agent authorization.

This is also where audit stops being compliance theater. Audit records for denied pipe operations should include a receipt with source handle, target capability, principal, policy version, and reason code.

Code execution makes the runtime more important

Code execution is going to win because less context and fewer round trips are worth the workflow tradeoff. The CE-MCP paper, From Tool Orchestration to Code Execution, formalizes the jump from context-coupled execution in MCP to context-decoupled code execution in MCP. The paper also introduces sixteen different attack classes that can be launched through five different execution phases of code execution.

Similarly, LangChain defines the sandbox-as-tool pattern with the agent and its state outside of the sandbox, API keys outside of the sandbox, and the execution state of the sandbox separate from the agent state. This structure is nice as it provides a natural home for the platform to manage the credentials, the policy, the trace context, and other runtime state for the generated code, model, and harness, rather than having it all in a generated code file in a harness.

Another AI tooling fallacy: code execution is simply another loop around the model, with potentially cheaper rounds of computation. This misses the mark fundamentally. Execution has become a privileged substrate within the AI-powered end-to-end workflow, and one that cannot be governed by simple prompt-level rules. It requires a runtime policy broker to adjudicate the required authorizations along the way.

Enterprise security teams will ask for receipts

Once agents are running across employee accounts inside a company, there is real security work in running an MCP runtime. A buyer has to confirm that the runtime has implemented the functions listed in Arcade’s guide to MCP gateways, runtimes, and registries: OAuth lifecycle management, credential storage in a vault, multi-user support with respective authentication and authorization, permission intersection, auditing, policy management, enforcement, and observability.

Zuplo’s 2026 protocol-stack post separates the MCP used for agent-to-tool communication from the A2A used for agent-to-agent communication. Such a split makes sense because while MCP allows an agent to communicate with tools, A2A enables one agent to directly communicate with another agent. Gateways for cross-agent communication will enable functions such as token binding, request validation, capability filtering, and full request logging.

From an auditable decisions standpoint, we would document each decision in a detailed record which includes: principal_id, agent_id, grant_id, resource_id, capability_id, input_handle_ids, output_handle_id, policy_version, decision, reason_code, and trace_id. All of the information from the allow path and the deny path for a particular invocation, tied back to the conversation or workflow from which the invocation was invoked. We have made the same argument from the observability side: a conversation-level audit trail gives incident response a spine instead of a pile of disconnected spans.

This is where we start to put the AI agent security practices to work. If an agent is sending emails, the receipt should name the user principal, canonical mailbox, send grant, attachment handles, and policy version. If an agent created a Salesforce opportunity, then the receipt should list the same information against the opportunity as the canonical resource in that system. The same would hold for creating a new pull request.

No magic here. Just a dull and thankless job of documenting model-driven side effects.

Own the tool call

Just as we moved from unusual tool access to the normal usage of tools via MCP, now every meaningful tool call must be treated as an event for the following classes: authorization, who is allowed to make this call; data flow, what is the input to the tool and what are the handles to its output; and audit, a record of every such call.

The first part of the test is not hard: tool calls should require different policy. A read-only weather API is different from a payment API, for example. A chart generated by a model is different from an external email. The API calls should be treated differently by the runtime, and therefore by the agent, which is programmed by a human.

The test I care about is this: can an operator explain why a particular tool call was permitted or denied by the AI agent or program without relying on the transcript of the conversation as the source of truth?

If that cannot be determined beyond the model’s transcript, then the agent security program is based on manners, and it matters not whether the system uses MCP, OAuth, a nice organized catalog of approved tools, and a tidy approval prompt dialog. The real boundary is the tool call itself, and either the runtime owns that boundary and all the vagaries of the model, tool metadata, the sandbox in which the generated code runs, and the APIs that the runtime and the model and the generated code in turn call, or the runtime inherits all that.

Own the tool call. Write the receipt. Make denial a first-class path.