Separating Intelligence and Authority in Agentic Systems

Security in agentic AI systems is not a behavioral trait that emerges from making a single language model larger or more politely aligned. Just as open-ended intelligence is a property of how a cognitive system is organized (Note #06), safety in tool-using agents is a structural property of the architecture and of how permissions compose across interacting agents and humans. Many of the sharpest risks in AI coding harnesses are classical software and operating-system problems — path traversal, symlink races, subprocess escapes, unauthorized network egress, and secret leakage — accelerated to machine speed by autonomous tool chaining. We examine why the two dominant industry responses — static string blacklists and asking a second language model to act as a live security judge — break down in practice, and how a neurosymbolic division of labor solves both problems at once.

An autonomous software-engineering agent cannot do useful work from inside a sealed text box. To fix a bug or verify a patch, it has to read issue reports, inspect repositories, unpack archives, run test suites, and commit code. That practical requirement creates what security researchers call a Living-off-the-Land environment: an attacker who sneaks an instruction into an external bug report or web page does not need to upload malware. They only need to nudge the agent into calling the legitimate tools already sitting on the machine — using find to spawn a shell, tar to overwrite a configuration file outside the workspace, or curl to send environment variables to an external address.

In multi-agent setups, the problem compounds across turns. One agent, whose context has become untrusted after reading an external ticket, can write a seemingly harmless helper script into the shared workspace. A second agent, which never read the untrusted ticket and holds network permissions, later runs that script — laundering untrusted instructions across the shared disk.

Today's standard defenses try to catch these failures in two ways, and both hit a structural wall:

1. Static string blacklists (Regex) look for obvious forbidden text patterns like curl | sh or /etc/passwd. Because they only inspect one command string at a time without understanding file paths, encoded arguments, or how data moved across the workspace, they miss more than half of structured attacks.
2. Language-Model Judges (LLM-as-a-Judge) place a second language model in the execution path and ask it to vote ALLOW or BLOCK on every tool call. Confronted with dual-use developer commands like pytest, git, or tar, a probabilistic judge cannot verify filesystem boundaries from a string of text. To avoid letting an exploit slip through, it defaults to conservative refusal — bringing normal software engineering work to a standstill while adding hundreds of milliseconds of delay to every action.

Our research prototype, ActiveSecHarness, addresses this by separating what neural models do well from what deterministic code must guarantee: intelligence may propose actions, but it never defines its own authority.

The architecture rests on four coordinated principles:

1. Narrowing Authority Under Delegation

Whenever an orchestrator delegates a task to a sub-agent, the sub-agent receives a cryptographic permission token whose scope can only narrow, never widen. A sub-agent spawned to run unit tests in a subfolder cannot silently inherit the parent agent's network or credential access.

2. Context-Aware Information Flow Across Agents

If a security system simply locks up the moment an agent reads an untrusted bug report, the agent can never edit code or run a test to fix the bug. Instead of a crude binary lock, we distinguish between raw untrusted input, source code derived from working on an issue, and sensitive secrets. After reading an external issue, the agent remains free to edit workspace files and run isolated local tests, while external network transmissions and privileged shell flags are deterministically blocked. Crucially, every file written to the shared workspace carries a record of which agent wrote it and under what trust state, so collaborating agents cannot launder untrusted data through the disk.

3. Checking Boundaries Where Resources Are Opened

Instead of guessing a command's intent from surface text, deterministic guards check the actual resource invariants at the moment a tool, file, or network socket is opened: stripping obfuscated encodings, resolving real file paths before an archive unpacks, checking file headers, and blocking unpinned network connections.

4. Using Language Models Where They Belong: Review and Human Learning

Taking language models out of the live permission-granting path does not mean leaving them out of security. It frees them to work asynchronously where pattern recognition and language actually help:

• Self-Healing Code Verification: When an agent writes application code, two models review the logic in the background and synthesize new security regression tests. A synthesized test is accepted into the project suite only if it passes a strict three-part check: it must fail on the vulnerable code, pass on the patched code, and pass on benign code without false alarms.
• Building Human Understanding: Security tools that silently block commands train developers to turn the guardrails off. Whenever a deterministic boundary stops an unsafe action, the system generates a concise, progressive explanation in an operator notebook — explaining the concrete risk and the underlying software principle at the developer's own level of experience.

We tested this architecture across 252 benchmark cases (120 single-step attacks across six threat categories, 120 realistic benign software-engineering actions, and 12 five-stage multi-agent attack chains), comparing five setups on the exact same tool calls:

Three findings stand out from the series:

• Deterministic boundaries beat probabilistic guessing (EXP-31): Static regex filters catch simple command pipes but miss 75% to 82% of archive escapes, obfuscated secrets, and sandbox breakouts. The live local language-model judge (qwen3:4b) stops the attacks only by refusing 118 out of 120 legitimate developer actions at more than ten thousand times the latency. Checking path, permission, and dataflow invariants deterministically blocks all 132 single-step and multi-stage attacks with zero false positives in 13 microseconds.
• Cross-agent provenance stops workspace laundering (EXP-32): Across 12 multi-agent laundering chains where one agent stages an artifact on disk for another agent to execute, tracking provenance across the shared workspace blocks all 12 of 12 chains, compared to 2 of 12 for single-agent memory tracking. At the same time, distinguishing derived engineering work from raw untrusted input cuts false blocks on post-issue coding tasks from 70% down to 0%.
• Verifying synthesized security tests (EXP-33): Across 30 Python modules and 12 candidate synthesized security tests, requiring every model-proposed test to pass the three-part Red-Green-Benign check admits 4 of 4 valid tests and filters out 8 of 8 broken or overly broad tests, raising vulnerable-code detection to 100% with zero false alarms on clean code.

ActiveSecHarness is a research prototype, not a standalone security product. We built it to test a question that every organization deploying capable agents will eventually face: how do we give AI systems the room to reflect, explore, and act across complex tools without surrendering human authority over what actually runs? The answer is the same principle that runs through all of our research: do not ask a single black box to do everything. Use models to imagine, propose, and reflect — and use explicit, inspectable architecture to govern memory, verification, and authority.

• Read Note #06: Beyond the Scaling Ceiling — Co-Recursive Semantic Self-Extension
• Read Note #01: A Small Model and a Stack of Rules — Our Run at STATE-Bench