Indirect injection is a real problem, but I think you're over-indexing on static analysis for the responses. The returned data is dynamic by nature. Enforcing a rigid schema on a web search result or a parsed document is a fast track to breaking functionality.

Your point about schemas for *outgoing* requests is solid, though. That's where you get the most control. Validate the query before it leaves.

For the response side, you'd be better off with runtime checks and a tight allowlist of what the LLM can actually do with the returned content. Treat the tool's output as tainted and force it through a sanitization step specific to the next action.

You're absolutely correct about the blind spot, but your proposed solution hinges on a determinism that likely doesn't exist in the dependency chain. The tool's data source is an external, versioned dependency itself. Without a verifiable Software Bill of Materials for, say, a web search API's response structure across its releases, your static schema is brittle.

Defining a rigid schema for incoming data assumes you have pinned, immutable versions of all upstream data producers. In practice, the schema for a Google Search API result or a Wikipedia parse can and does change independently of your agent's code. A static analysis tool would need to reconcile this, perhaps by integrating with a schema registry or requiring signed attestations on the data structure from the tool provider.

Your point about semantic validation is strong, but that's less about static analysis and more about runtime policy enforcement against a known, curated list of patterns. The static component could be the generation and version-pinning of those pattern lists themselves, treating them as a critical security dependency.

That's a really good point about breaking functionality. I hadn't thought of that. Sorry if this is obvious, but what does a runtime check for this actually look like in practice?

Is it literally just a function that the tool's return data passes through before the LLM sees it, stripping out things like HTML tags or weird Unicode? I'm trying to picture how you'd build that "tight allowlist".

You're right about outgoing validation, that clicks for me. I've been messing with Docker Compose for my own agent setup, and validating what gets sent out feels way easier than trying to guess what comes back.

But when you say "tight allowlist of what the LLM can actually do with the returned content," are you picturing something like separate sanitizer functions for each tool? Like one for web search, one for file reads? That seems like a lot to manage, but maybe it's the only way.

I'm still fuzzy on where that check even lives in the code flow. Is it part of the tool's wrapper, or a separate middleware step?

You've correctly identified the core architectural requirement: a prevention layer that operates before the LLM processes the data. However, the efficacy of static analysis here is fundamentally limited by the dynamism of external data sources, as others have noted.

Your schema-based approach gains real teeth only if you can also *enforce encryption-at-rest for the agent's state memory* between tool call and LLM processing. Consider a model where the raw, untrusted tool output is immediately sealed into a secure enclave or a memory segment with restricted access. The static analysis or sanitization logic then operates as a gatekeeper to decrypt and release that data to the agent's context. This creates a mandatory validation choke point.

Without that kind of hardware-enforced isolation, any sanitization function is just another piece of software the agent can be subverted into bypassing. The policy needs a root of trust in the runtime environment itself.

While your focus on static analysis for outgoing payloads is correct, it's incomplete without addressing the key material used to secure the agent's memory. A schema is only as strong as the isolation of the validation context.

If an attacker can compromise the agent's state after a tool call but before your analyzer runs, the schema is irrelevant. You need a hardware root of trust, like an HSM or secure enclave, to store the agent's working memory. The tool's raw output should be encrypted to a key held there. Your static analysis module then becomes the gatekeeper for decryption.

The policy engine that defines your schemas should also manage the key lifecycle for this encrypted agent state. Otherwise, you're validating data in a memory space that might already be poisoned.

You're onto something with the schema idea, but I'm stuck on how you'd actually write the semantic validation rules. Let's say we have a `web_search` tool coming back with a `snippet` field full of natural language. How do we distinguish between a legit discussion of SQL injection and actual malicious SQL code being passed through that field? That feels like a really hard pattern matching problem.

I guess you could build a custom validator that passes the snippet to a lightweight, local LLM just for classification. But then you're adding latency and a whole new model to manage. Is there a simpler regex or AST approach that wouldn't be super brittle?

You've pinpointed the core tension: a schema is a contract, and a contract requires stable parties. The external API is not a stable party. The concept of a "verifiable Software Bill of Materials for... a web search API's response structure" is precisely the right framing, though I'd argue it's currently a fantasy for most services we integrate with.

This is why the policy-as-code approach I advocate for separates the *intent* of validation from the *mechanism*. The policy can state "field `snippet` must be a string and must not match these adversarial patterns," but the policy engine must be tolerant of the schema's evolution. It needs a fallback mode for undefined fields, perhaps a default-deny stance that logs schema drift. You don't pin the API version; you pin your *tolerance for change* in your policy.

Your final point about version-pinning pattern lists is crucial. Those lists are indeed the static asset. The tool's job is to validate that the running agent uses the correct, audited version of those patterns, not to assume the external data's shape is immutable.