Securing the Agent's Tools, Not Just the Agent

Table of Contents

• Why the Tool Layer Is the Real Attack Surface
• The Mental Model Shift: From "Trust the Agent" to "Trust Nothing It Calls"
• What "Securing the Tools" Actually Means
• Capability Scoping at the Tool, Not the Prompt
• Per-Invocation Authorization
• Output Sanitization Going Back Into the Agent
• The MCP Problem: A Standard That Made This Harder
• Common Mistakes Teams Make
• A Practical Defense Architecture
• What This Means for GaaS Buyers and Vendors
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

Why the Tool Layer Is the Real Attack Surface

Here is the uncomfortable truth that a lot of agent vendors would rather not lead with: a language model, on its own, is inert. It produces text. It cannot delete a production table, refund a customer, email your vendor list, or wire money. It can only ask to do those things. The asking becomes doing the moment a tool executes the request.

That distinction is the whole game. When people say "the agent did something dangerous," what physically happened is that a tool the agent had access to executed an action with the agent's credentials. The model was the decision-maker, but the tool was the actuator. And in most real deployments, the actuator is the weakest link, not because the tools are badly built, but because they were never designed to be driven by an unpredictable, persuadable, occasionally-hijacked operator.

Think about how traditional software calls an API. A human wrote the code path. It's deterministic. The same inputs produce the same calls, every time, and a security reviewer can read the code and know the blast radius. An agent breaks that assumption completely. The sequence of tool calls is generated at runtime from natural language, and that natural language can come from a customer, a web page the agent scraped, a document it was asked to summarize, or an attacker who slipped instructions into any of those. The tool doesn't know the difference. It just sees a well-formed request from an authenticated agent and does its job.

This is why hardening the model alone is a losing strategy. You can make the model 99% resistant to manipulation, and the 1% still reaches a tool that executes with full privileges. Security people have a name for this pattern, defense that depends on a single probabilistic gate, and they don't say it admiringly.

The Mental Model Shift: From "Trust the Agent" to "Trust Nothing It Calls"

The mature framing borrows directly from zero-trust networking. In zero trust, you stop assuming that anything inside the perimeter is safe; every request gets authenticated and authorized on its own merits. Agent security needs the same move, pushed down to the tool boundary: assume the agent will eventually be wrong, manipulated, or compromised, and design the tools so that a bad request can't do catastrophic damage even when it gets through.

That sounds obvious when you write it down. In practice almost nobody builds this way, because the easy path is the opposite. The fastest way to ship a capable agent is to hand it a fat service account with broad scopes, give it a pile of tools, and let the model figure out which to call. It demos beautifully. It's also how you end up with an agent that, given the right adversarial nudge, can read every customer record in the database because the tool it uses for one lookup was granted table-wide read access.

The shift is from securing the reasoner to securing the reach. The reasoner will always be fallible, that's the nature of probabilistic systems. The reach is something you control deterministically, with code, policy, and infrastructure. That's where your leverage is.

What "Securing the Tools" Actually Means

This phrase gets used loosely, so let's make it concrete. Securing the agent's tools is not one control; it's a layered discipline across three distinct concerns.

Capability Scoping at the Tool, Not the Prompt

A huge number of teams "restrict" an agent by telling it, in the system prompt, what it's allowed to do. "Only issue refunds under $50." "Never delete records." This is not a security control. It's a suggestion to a system that is, by design, talkable-out-of-things. Prompt injection research has shown repeatedly that instructions embedded in the model's context can be overridden by other instructions, and an attacker's whole job is to supply those other instructions.

Real scoping lives in the tool. The refund tool itself enforces the $50 ceiling and rejects anything above it, regardless of what the model "decided." The delete capability simply isn't in the agent's toolset, or it's behind a separate tool that requires a human approval token. The principle here is the same least-privilege design that underpins least-privilege access in modern cloud security, applied to the agent's hands rather than a user's IAM role. If a capability would be dangerous when misused, it should be physically impossible to invoke past its safe bounds, not merely discouraged in prose.

The common mistake: treating the system prompt as a policy engine. The better approach: every constraint that matters is enforced in deterministic code at the tool, and the prompt is treated as guidance the agent might ignore.

Per-Invocation Authorization

Most agents authenticate once and then operate on a long leash. A better model authorizes each tool call against the context it's running in: which user is this agent acting for, what's the value of this action, has this same action been attempted three times in the last minute (a sign of a loop or an attack), does this call fall outside the agent's normal behavioral envelope?

This is where tool security overlaps with the broader question of identity for non-human actors that the GaaS governance literature keeps circling. The agent needs an identity, yes, but the tool needs to evaluate that identity per call, with the specific parameters in hand, not just wave it through because the session is valid. A refund tool should care that this refund is for $9,000 even if the agent is "authorized to issue refunds" in general.

Output Sanitization Going Back Into the Agent

This is the part almost everyone forgets. Tool security isn't only about controlling what the agent sends out to a tool, it's about what the tool sends back in. When an agent calls a tool that fetches a web page, reads a support ticket, or pulls a record, that returned content goes straight into the model's context as fresh instructions-shaped text. That's the prompt-injection supply chain. A malicious string in a scraped page becomes a command the agent may follow on its next turn.

Securing the tool here means treating tool outputs as untrusted input: stripping or clearly delimiting instruction-like content, flagging anomalies, and never letting raw external content flow into a privileged decision without a boundary. Anthropic's own guidance on building agents and tool use emphasizes structured, bounded tool definitions for exactly this kind of reason, the cleaner the contract, the smaller the room for injected instructions to maneuver.

The MCP Problem: A Standard That Made This Harder

The Model Context Protocol (MCP) deserves specific attention because it's becoming the default way agents connect to tools, and its convenience cuts both ways. MCP makes it trivial to plug an agent into dozens of tool servers. That's wonderful for capability and genuinely dangerous for security, because every MCP server you connect is a new actuator with its own permissions, its own trust assumptions, and often its own author you've never met.

The failure modes are predictable once you look. A third-party MCP server can describe its tools however it likes, and those descriptions land in the agent's context, meaning a malicious server can inject instructions just by being connected. Tool names can collide or shadow each other. A server can quietly change what a tool does after you've approved it. And because MCP lowers the friction of adding tools to near-zero, organizations accumulate them the way they once accumulated browser extensions: enthusiastically, and without anyone tracking the aggregate blast radius.

The lesson isn't "don't use MCP." It's that the protocol moves the security burden onto you, the integrator. Every connected server needs the same vetting you'd give a vendor with API access to production, because that's effectively what it is. Securing the agent's tools, in an MCP world, means securing your supply chain of tools, and that's a governance problem at least as much as a technical one.

Common Mistakes Teams Make

A few patterns show up over and over once you start auditing real agent deployments:

• The fat service account. One credential with broad scopes shared across every tool the agent uses. When the agent is manipulated, the attacker inherits all of it at once. Each tool should run with the narrowest credential that lets it do its one job.
• Confusing logging with control. Teams proudly show audit logs of every tool call, after the fact. Logs are necessary for forensics and the audit trails regulators will eventually demand, but a log is not a guardrail. It tells you the barn door was open; it doesn't close it.
• Approving tools, not actions. A human approves that the agent may use a payment tool, then never sees the individual $40,000 transaction it pushes through at 3 a.m. Approval needs to attach to high-stakes invocations, not blanket capabilities.
• No rate or velocity limits. Agents loop. A bug or an attack can fire the same tool hundreds of times in seconds. Without per-tool velocity caps, a small error becomes a large incident before anyone wakes up.
• Trusting tool output blindly. Covered above, but it's the single most underweighted risk. The data coming back from a tool is part of your attack surface.

A Practical Defense Architecture

If you're building or buying a GaaS product and want tool-layer security that holds up, here's a workable shape. None of it is exotic; the discipline is in actually doing all of it.

Put a policy-enforcing proxy between the agent and every tool. The agent never talks to the database, the payment processor, or the third-party API directly. It talks to a broker that authenticates the agent, checks the specific parameters of each call against policy, enforces value ceilings and velocity limits, and can demand a human approval token for actions above a threshold. This is the single highest-leverage piece, because it turns probabilistic model behavior into a deterministic chokepoint you control.

Give each tool its own least-privilege credential, issued just-in-time and short-lived rather than a standing key. Pair this with proper secrets management for agents at scale so credentials are never sitting in the prompt, the code, or the model's context where an injection could exfiltrate them.

Sandbox anything with side effects. Code execution, file operations, and shell access run in isolated, ephemeral environments with no network egress by default and no path back to production credentials. Containment is what keeps a single bad call from becoming a breach.

Treat tool outputs as untrusted, with a sanitization and delimiting layer between what a tool returns and what re-enters the model's context.

And make the whole thing observable in real time, not just logged, but monitored, with anomaly detection that can trip a kill switch when an agent's tool-call pattern goes sideways. Forensic logs matter, but live monitoring is what shortens an incident from hours to seconds.

What This Means for GaaS Buyers and Vendors

For buyers, this reframes the security questionnaire. Stop asking only "how is your model aligned?" and start asking "what can your agent's tools actually do, and what stops them from doing more?" Ask where constraints are enforced, prompt or code. Ask whether each tool has its own scoped credential. Ask what the human-approval boundary is and whether it attaches to actions or capabilities. A vendor who can answer those crisply has thought about the real attack surface. A vendor who talks only about guardrails and alignment has secured the brain and left the hands free.

For vendors, tool-layer security is becoming a buying criterion and, increasingly, a differentiator you can charge for, the same way SOC 2 became table stakes. The teams that win enterprise GaaS deals will be the ones who can draw the diagram above and point to where every dangerous capability is bounded in code. As McKinsey's work on scaling generative AI safely in the enterprise keeps underlining, the blocker to adoption usually isn't model quality, it's whether the organization can trust the system with real access. Tool security is how you earn that trust.

Insights Most People Overlook

The agent is the least trustworthy component you'll ever give production credentials to, and that's fine, if you design for it. We obsess over making the model more reliable. The more durable move is to assume it never will be fully reliable and put the trust in the deterministic layer around it. A mediocre model behind excellent tool governance is safer than a brilliant model with broad, unbounded access.

Tool security inverts the usual prompt-injection conversation. Everyone discusses prompt injection as an input problem, how do attackers get malicious instructions in? The more tractable question is the output one: even if the injection succeeds, what can the agent actually do with it? If the answer is "nothing dangerous, because the tools won't allow it," prompt injection drops from existential to annoying. You can't reliably stop the injection; you can absolutely bound its consequences.

MCP's biggest risk isn't a clever exploit, it's accumulation. No single connected tool server feels risky. The danger is the twentieth one you added without removing any, each expanding the agent's reach, none owned by anyone tracking the total. Agent tool sprawl is the new shadow IT, and it grows precisely because the protocol made adding tools frictionless. Periodic tool-inventory audits will catch more real risk than most red-team exercises.

"Human in the loop" is meaningless without specifying the loop. A human approving that an agent may use a tool, once, at setup, is not in any meaningful loop. The loop that matters is per-action and risk-weighted: the human sees the $40,000 transfer, not the capability to transfer. Most "human oversight" claims collapse under this distinction, and buyers should press on exactly which actions trigger a human and which don't.

Securing tools well makes your agent more capable, not less. This is counterintuitive and important. When the dangerous edges are bounded in code, you can safely hand the agent broader, more useful tools, because a mistake can't escalate. Teams that skip tool security end up forced to keep their agents weak and supervised, not because the model can't do more, but because they can't afford the blast radius. Good tool security is what lets you take the training wheels off.

Frequently Asked Questions

Isn't securing the model enough if it's good at refusing bad requests? No, and the reason is structural. Model refusal is probabilistic, it works most of the time, which means it fails some of the time, and attackers optimize for that failure rate. Tool-layer controls are deterministic. The combination is strong; the model alone is a single point of failure.

Where exactly should a constraint like "max refund $50" live? In the refund tool's code, enforced before the action executes. Putting it in the system prompt makes it advisory, and anything advisory can be argued away by injected instructions. If a limit matters, it must be unbreakable by the model, which means it lives below the model.

Does a policy-enforcing proxy add too much latency for production agents? In practice the authorization check is microseconds against tool-call latencies measured in hundreds of milliseconds or more. The proxy isn't your bottleneck; the API and model calls are. The latency objection is almost always a rationalization for skipping the work.

How is this different from normal API security we already do? The caller is fundamentally different. Traditional API security assumes a deterministic, code-driven client. Agent tool security has to assume a non-deterministic client whose next call is generated from natural language that may include attacker-supplied content. Per-invocation authorization, value ceilings, and treating tool outputs as untrusted are the additions that classic API security didn't need.

We use MCP for everything. What's the one thing to do first? Inventory your connected tool servers and treat each as a vendor with production access, because it is. Then put the agent behind a broker so no MCP server is talking to anything sensitive directly. Connection convenience is the trap; brokered, vetted access is the way out.

Can't we just give the agent read-only access to be safe? Read-only sounds safe and often isn't. Reading every customer record and exfiltrating it through a tool that "only reads" is still a major breach. Scoping has to be about which records and how much, not just read-versus-write.

Conclusion

The center of gravity in agent security is moving, and it should. For two years the conversation has been dominated by the model, alignment, guardrails, refusals. Those matter, but they protect the decision-maker while leaving the actuator exposed. The agent's tools are where intent becomes action, which makes them where security actually has to live.

The takeaways are concrete. Enforce constraints in deterministic tool code, never in the prompt. Authorize each invocation against its specific parameters, not just the session. Treat tool outputs as untrusted input back into the model. Give every tool its own least-privilege, short-lived credential, and put a policy-enforcing broker between the agent and anything that matters. In an MCP world, govern your tool supply chain as deliberately as you'd govern any vendor with production access.

The most common mistake is securing the brain and forgetting the hands, building elaborate model guardrails while a fat service account sits behind them waiting to be exploited. The practical next step is unglamorous: audit what your agent's tools can actually do, find the capability with the largest blast radius, and bound it in code today. Do that across your toolset and prompt injection stops being a headline risk and becomes a managed one. Secure the reach, not just the reasoner, that's the whole discipline in a sentence.

References

• Using IAM Securely (Least Privilege), Google Cloud
• Tool Use, Anthropic Documentation
• QuantumBlack: Our Insights on Scaling AI, McKinsey