When Prompts Become Shells: The Tool Registry Is the Attack Surface

A prompt is only text until there is a tool behind it

A language model with no tools is, from a security standpoint, mostly harmless. It can be tricked into saying regrettable things, but it cannot reach out and touch a database, send an email, spend money, or run a shell. The instant you register tools, that changes categorically. Now the model’s output can name a function, and that function does something in the real world. The prompt stopped being text and became, effectively, a shell—an interpreter turning natural language into privileged calls.

This reframes the whole security question. Teams spend enormous effort trying to make the model refuse bad instructions. Useful, but secondary. The primary fact is simpler and more uncomfortable: the agent can only ever do what is in its tool registry. Everything reachable by a successful prompt injection is exactly the set of tools you registered. The registry is the attack surface.

Untrusted input is closer than you think

“But I control the prompt” is the reassurance that fails. You control the system prompt. You do not control the web page the agent summarizes, the PDF it parses, the support ticket it triages, the email it reads, or the API response it ingests. All of that is untrusted content flowing into the same context window where the model decides which tool to call. Any of it can carry instructions. If a destructive tool is registered, any of those channels can, in principle, fire it.

Two moves that actually shrink it

You reduce this attack surface the same way you reduce any privilege surface: fewer grants, and a checkpoint on the dangerous ones.

1. Treat every registered tool as a privilege grant

Before adding a tool, ask the question you would ask before granting a production credential: does this task actually need it, and what is the worst a single call can do? Split read-only tools from destructive ones. Scope each tool as tightly as it will go—a query_orders that can only read the caller’s own orders is a smaller surface than a generic run_sql. A registry curated this way turns most injections into dead ends because the tool the attacker wants was never registered.

2. Put a pre-execution gate on the destructive ones

For the tools you must keep—the ones that write, delete, spend, or execute—add a deterministic gate between the model’s decision and the effect. The model can still be injected into asking. The gate decides whether the ask is honored, in code the attacker cannot talk their way past.

# pip install constitutional-agent
from constitutional_agent import Constitution

constitution = Constitution.from_defaults()

async def dispatch_tool(tool_call, ctx):
    # Read-only tools clear a lightweight path.
    if tool_call.is_read_only:
        return await tool_call.execute()

    # Destructive tools must clear the gate first.
    decision = constitution.evaluate({
        "proposed_spend": tool_call.blast_radius,
        "approved_budget": ctx.get("approved_blast_radius", 0),
        "gate_override_without_amendment": tool_call.is_destructive,
        "failing_tests": ctx.get("untrusted_input_present", 0),
    })

    if decision.system_state.value == "FREEZE":
        return Blocked(reason=decision.gate_results)   # prompt-as-shell defused

    return await tool_call.execute()

The gate is framework-agnostic—it does not care whether the tools come from MCP, native function-calling, LangGraph, or a hand-rolled loop. It cares only that a destructive invocation, however it was triggered, has to pass a deterministic check whose answer the model does not get a vote on.

You cannot make a language model injection-proof; that is an open research problem. You can make sure that even a perfect injection lands on a small, scoped registry with a gate in front of anything that bites.