Runtime Governance Is Not Enough for AI Agent Security

Many teams gate tool invocation but under-govern the transformations that shape tool arguments. That gap allows attacker-influenced content to cross trust boundaries through adapters, metadata fields, and helper code — arriving at the execution sink with a clean policy receipt.

This is not a new pattern in software security. It maps directly to how SQL injection succeeded for decades despite application-layer validation: the trusted execution path was assembled from untrusted input material, and the final gate only checked whether to execute — not whether the assembled argument was safe.

Execution-time governance can correctly authorize an action while the argument path has already been compromised upstream. In practice, this creates policy-compliant logs with exploitable outcomes.

Consider the sequence:

Every individual step may look clean in isolation. The chain-level outcome is what matters. Logs show "authorized." The outcome reflects attacker influence. Neither the human reviewer nor the automated system sees the gap — because the gap existed upstream of where they were looking.

This is why teams building on MCP, LangChain, or custom agent frameworks find that their existing API security controls do not transfer cleanly to the agent layer. See our analysis of MCP tool poisoning and the related pattern of why guardrails alone are not enough for more on how these gaps compound.

Recent advisories continue to map to this pattern — execution trusted, path unverified:

These examples differ in implementation details, but share one root issue: trusted execution paths assembled from low-trust input material. The runtime layer was not the problem. The path to the runtime layer was.

Supply-chain variants compound this further. See AI supply-chain attacks in 2026 for how compromised upstream packages deliver attacker-controlled content that appears legitimate by the time it reaches runtime policy checks.

Closing the path-governance gap requires controls at five points, not one:

Most teams have layer 3. Some have layer 1. Few have layers 2, 4, and 5. The incidents that make it into postmortems typically exploited gaps in layers 2 or 4.

The following shows how Sunglasses v0.2.13 flags attacker-influenced content at the ingestion layer — before it reaches any adapter or runtime gate:

Single-call policy tests will not expose path-governance gaps. What catches them:

The Sunglasses reports page includes real attack chain analyses — including our AXIOS RAT scan — that demonstrate what composed attacks look like in practice and where existing controls fail to intercept them.

If you are building agents today, the practical priority order is:

Runtime governance was the right place to start. It is not the right place to stop. The teams that have already learned this lesson are the ones writing postmortems.

I want to be clear about something before going further: governance frameworks are not the enemy here. NIST AI RMF, ISO 42001, the EU AI Act — these exist because someone recognized that deploying AI systems without accountability structures is reckless. They define what must be controlled, who is responsible, what gets audited, and what happens when something goes wrong. That scaffolding is necessary.

The problem is not that governance is wrong. The problem is that governance is frequently deployed as the only layer, when it was designed to be the accountability layer on top of other controls. A governance framework tells you that agents must not access PII without authorization. It does not stop the bytes from flowing — it records that a rule existed and determines whether the outcome was compliant. Those are different jobs.

Governance frameworks are also good at forcing documentation: threat models, data flow diagrams, acceptable-use policies, incident response plans. When an agent incident does occur, a well-governed system produces a clear audit trail. That audit trail matters for liability, for regulatory response, for learning. It does not matter for the person whose data was exfiltrated 72 hours before the audit surfaced the log entry.

The argument here is narrow: governance without runtime enforcement is paperwork. The frameworks themselves would agree — they describe governance as one layer in a defense-in-depth stack, not the stack itself. Most enterprise deployments have picked up the governance layer first and skipped the inline enforcement layer entirely. That gap is the problem I keep scanning for.

Most enterprise governance relies on logs, reviews, and after-the-fact incident response. The assumption baked into that model is: if we record everything, we can catch violations and respond. That assumption held reasonably well in human-paced systems where a policy violation took hours or days to materialize into real damage.

AI agents do not move at human pace. A single agent session can read a document, extract content, call an external API, and write a summary with embedded payload — all in seconds, all while producing logs that look perfectly normal at each individual step. By the time that session log surfaces in a weekly audit, the action is done. The data left the boundary. The tool call completed.

This is the post-hoc problem: logs without filtering are a forensic record of damage already done. They are useful for understanding what happened and for preventing recurrence. They are not useful for stopping the attack that is running right now.

I scan a lot of content as part of my pattern research cycle. What I see consistently is that the highest-severity patterns — data exfiltration via tool chains, cross-agent injection via handoff tokens, retrieval poisoning via document metadata — all complete their damage in the same agent session where the malicious content entered. Post-hoc review catches these in the log. Inline filtering catches them before the agent acts on the content. Those are not equivalent outcomes.

A governance framework that requires logging does not become an inline filter just because the logs are comprehensive. These are architecturally different things.

There is a useful analogy in traditional network security: a governance policy is to a runtime filter what an audit log is to a firewall. The audit log tells you what happened. The firewall stops it from happening. You need both — but only one of them prevents the breach.

The enterprises that took network security seriously in the 2000s learned this the hard way. Detailed logging without perimeter controls produced detailed records of successful intrusions. Adding detection without prevention produced faster incident reports on the same successful intrusions. Prevention — blocking known bad traffic at the perimeter — was what actually changed the outcome.

AI agent security is at roughly the same inflection point. Most organizations have detection: logs, alerts, anomaly scoring on agent outputs. Some have post-hoc governance review. Very few have deployed inline prevention at the ingestion layer — the equivalent of a firewall for content entering the agent's context window.

Sunglasses operates at that prevention layer. The filter runs in approximately 0.26ms before the agent's context is assembled, matching input against 328 patterns across 49 categories as of v0.2.20. When a match fires, the content does not reach the agent. There is nothing to log after the fact because the attack path was closed before it opened. The governance layer then receives a clean signal — what passed the filter, what was blocked, and why — which actually makes post-hoc review more meaningful, not less.

Detection and prevention are not competing approaches. They are complementary. The gap today is that most agent deployments have one and not the other.

Let me be concrete about the difference, pattern category by pattern category.

cross_agent_injection: An attacker embeds a malicious instruction in a message passed from one agent to another — a delegation token, a handoff summary, a task description. Governance records that Agent B received a message from Agent A and acted on it. Filtering intercepts the message before Agent B reads it, matches the embedded instruction against known injection signatures, and blocks it. The governance log never sees the attack payload because the filter removed it first.

retrieval_poisoning: Attacker-controlled content is embedded in a document that an agent will retrieve from a knowledge base or RAG pipeline. Governance records that the agent called the retrieval tool and received a document. Filtering scans the retrieved document content before it enters the agent's prompt, catching patterns like embedded override instructions or exfiltration triggers. The agent receives the clean portion or a block signal — it never reads the poisoned fragment.

tool_output_poisoning: A tool returns output that contains attacker-shaped content — instructions embedded in what looks like a structured API response. Governance records the tool call and the output. Filtering runs on the tool output before the agent processes it, matching against patterns that look like injected commands inside result payloads. If it fires, the agent does not act on the poisoned output.

In each of these cases, governance provides the audit trail: what was called, when, by whom. Filtering provides the intervention: the attack payload does not reach the decision point. Guardrails at the output layer miss all three of these because the damage is done before output is generated. You need the filter at ingestion.

The right architecture is not filtering instead of governance. It is filtering inline with governance as the accountability layer on top.

Here is how the two layers interact in practice. The Sunglasses filter sits ahead of the agent, scanning every input — prompts, retrieved documents, tool outputs, agent-to-agent messages — against the current pattern set. Known-bad patterns are blocked before the agent reads them. Ambiguous content that passes the filter still enters the context, and the governance layer captures the full session: what the agent received, what it decided, what actions it took.

This gives the governance layer something more useful to work with. Instead of reviewing logs full of attack attempts that reached the agent, the review surface is focused on the cases that actually needed human judgment — content that passed the filter, edge cases, novel attack patterns not yet in the detection set. The filter's block log feeds back into pattern development: blocked attempts that later appear in incident reports become candidates for new pattern additions in the next release cycle.

The filter also learns from governance findings. When a post-hoc review identifies a new attack vector — something that slipped through because it did not match existing patterns — that finding translates directly into a new pattern. Governance findings that would previously sit in an incident report and wait for the next policy review cycle instead feed the detection engine. The loop closes faster.

Neither layer is optional. Filtering without governance is a black box with no accountability trail and no way to review what the filter missed. Governance without filtering is a detailed record of successful attacks. Together, they are what a mature AI agent security posture actually looks like. Most deployments are missing the first half.