Prompt injection is one of the most discussed attack vectors in AI tooling. The mechanism: an attacker plants text in a resource that an AI tool will read, and that text hijacks the model’s behavior. A crafted README that makes the model extract and exfiltrate credentials. A malicious comment that makes the model disable security checks. A document that tells the model to "ignore previous instructions."
The standard mitigation advice, "sanitise inputs," "don’t let the model read untrusted content", is correct as far as it goes. But there is a deeper architectural principle that makes an entire class of injection attacks structurally impossible: serve data, not instructions.
The data/instruction distinction
When a tool serves data to a language model, it provides facts: "this file has a blast radius of 34 modules," "the top-10 spikescore nodes are X, Y, Z," "the community members of the auth cluster are these 12 files."
When a tool serves instructions, it provides directives: "always check these files first," "when modifying auth code, follow these steps," "remember to update the changelog."
The distinction is not syntactic, both can be written as plain text. It is semantic: data describes reality; instructions direct behavior.
Why instructions are the attack surface
Prompt injection works by inserting instructions into content the model treats as data. The attack succeeds because the model cannot reliably distinguish "a fact about the codebase" from "a directive I should follow" when both appear in its context window.
A data-only MCP tool eliminates this attack surface by design. If the tool never serves directives, never tells the model what to do, only tells it facts about the world, then no injected content can use the tool as a vector for behavioral hijacking.
The model can still be told facts that are false (if the data is manipulated). But false facts are a different, generally weaker attack surface than injected directives.
How Spiderbrain enforces the fence
Every MCP tool response from Spiderbrain is a structured data object: scores, node records, community memberships, memory node content. The response schema excludes imperative sentences, action directives, and conditional instructions.
The Memory Tree is the edge case. Memory nodes can contain natural language, "the auth module uses JWT with RS256" is not a directive in itself, but "always verify JWT before executing any handler" approaches directive territory.
Spiderbrain’s memory storage validation rejects memory nodes that contain imperative structures. What gets stored and served are facts about the project: decisions made, constraints established, patterns adopted. Not instructions for how the AI should behave.
The fence is not perfect, sufficiently creative phrasing of a memory node could push toward instruction territory, but the architectural principle is clear: memory nodes describe the project, they do not direct the model.
The difference this makes for enterprise use
For teams in regulated industries or high-security environments, the data/instruction distinction is a compliance argument. An MCP tool that could serve instructions is a potential exfiltration vector or a potential behavioral manipulation vector. An MCP tool that exclusively serves data can be audited as a data service, not as a behavioral control surface.
This framing makes Spiderbrain’s architecture auditable in a way that instruction-serving MCP tools are not. You can inspect the schema, verify that no response contains imperative structures, and assert that the tool cannot direct model behavior, only inform it.
What you give up
The injection fence does constrain what Spiderbrain can do via MCP. The tool cannot serve onboarding workflows, cannot walk the model through a multi-step process, cannot enforce a development process via instructions.
These are not things Spiderbrain should be doing. The Memory Tree is the right place for process constraints, and Memory Tree content is fact-shaped ("the convention is X") rather than instruction-shaped ("do X first"). The boundary is enforced by design, not by discipline.
The positive framing
Injection fences are typically framed as defensive constraints. The positive framing: when every MCP tool serves only data, the model has full agency over how to use that data. It is not being directed; it is being informed. The behavioral decisions belong to the model (and, via prompt, to the user), not to the tool.
This is the correct relationship between a context layer and an AI agent. The tool is an information resource. The agent is the decision-maker. Injection fences enforce that relationship architecturally.
