Could dumb code, not the AI itself, decide which tools it's allowed to use — blocking hidden instructions from hijacking it?

This explores whether you can stop prompt injection by having ordinary code, not the LLM, decide which tools an agent is allowed to call. The corpus doesn't use the phrase "symbolic matching on tool names," but it has a lot on the underlying idea. The most surprising lesson is that checking *which* tool gets called is only half the defense. The other half is checking *what data* is passed to it.

The basic case for rule-based gating is strong. One paper describes six architectural patterns, including Action-Selector and Plan-Then-Execute, that resist prompt injection by cutting the path from untrusted input to consequential actions (Can structural design patterns block prompt injection attacks?). In Action-Selector, the model can only pick from a fixed menu of actions. Text it reads can't invent a new tool call, because the code accepts only allowed choices. The key claim is that system-level constraints give *guarantees*, while asking the model to "be careful" only lowers risk. A clever enough injection gets past a careful model. It can't get past a rule the model never evaluates.

Tool-name gating alone still leaves a gap. Willison's Dual LLM pattern keeps the planning model away from untrusted data, so an attacker can't rewrite the plan. CaMeL's authors show the attacker can still tamper with the *values* that flow through that plan (Does isolating planning from untrusted data actually stop prompt injection?). Suppose "send_email" is a permitted tool and the plan really does call it. The recipient address was pulled from a poisoned document, so the email goes to the attacker. CaMeL's fix is to attach metadata to every value recording where it came from. Policies can then block untrusted data from reaching sensitive tool arguments (Can capability tracking stop prompt injection attacks?). The cost is real but modest: it solved 77% of AgentDojo tasks, 7 points fewer than an undefended agent, but with provable policy compliance.

A related question is who gets to change the rules. Progent lets the LLM propose updates to its own tool permissions as a task unfolds. An SMT solver (a logic engine that checks rules mechanically), not the model, judges whether each update narrows or widens access. Safe narrowing is applied automatically, and silent widening is blocked even if the model has been manipulated (Can an SMT solver prevent LLM policy drift during agent execution?). The same principle runs through all these notes: the model can suggest, but only something it can't sweet-talk gets to decide.

The attack research shows where rule-based checks run out. FLOWSTEER injects at planning time, steering how a multi-agent workflow is put together before any tool-level check fires. That raised malicious success by up to 55% (Can prompts alone reshape multi-agent workflows without system access?). ColluSkill gets past skill scanners because they score each skill on its own. Every piece looks harmless, while the chain as a whole is malicious (Can attackers evade skill scanners by refining individual skills?). Even the layer that routes requests to models can be attacked (Can attackers manipulate which model handles a request?). So the honest answer: matching tool calls against an allowlist does block a whole class of hijacks, and it's more reliable than asking the model to resist. It works only when paired with tracking where each argument came from, and when the checks cover sequences of calls, not just each call alone.