Research prototype applies dual-lattice IFC to block privilege escalation in LLM coding agents

What the prototype does

A project post on dev.to introduces agent-harness-defense v0.2.0, an open research prototype intended to stop instruction-privilege escalation in LLM coding agents. The tool is an admission layer rather than a live firewall: a caller passes a structured Plan — what the agent intends to read, what it intends to write, and where each value comes from — to a run_admission() call, and gets back a verdict with the reason. The author presents it explicitly as a reference implementation with a rigorous audit, not a production defense.

The post grounds the motivation in two documented gaps. Harnesses assemble context on every invocation and can promote low-privilege material such as repository text or tool output to instruction level, making an agent obey what it would refuse at the original level, per a paper by Girrens and Wang. Separately, autonomous loops re-initialize their safety monitor on each trajectory, so attack evidence fragmented across iterations never appears in a single window. The post also points to an evaluation of coding-agent harnesses against 13 attack objectives across six real frameworks.

How the engine decides

The decision core is a dual-lattice information-flow-control engine. Each datum in a plan carries two labels: confidentiality, meaning how secret it is, and integrity, meaning how far the source is trusted. Reads are classified by path — repository text is labelled UNTRUSTED while system files are SYSTEM — and origins carry tags such as SYSTEM, USER, TOOL_RESULT, REPO_TEXT, ENV and DATA.

Evaluation applies a componentwise lattice join over the dependency graph. Confidentiality takes the maximum, so a result is as sensitive as its most sensitive input. Integrity takes the minimum, so an UNTRUSTED value joined with a SYSTEM intent stays UNTRUSTED — a no-upgrade rule. A write that depends on an untrusted read inherits UNTRUSTED integrity and is denied; writing a value sourced from an environment secret to a public sink is denied under the no-downgrade rule; a write depending only on system or user input is admitted. The older v0.1 heuristic built on trigger phrases and forbidden paths survives as a backup signal rather than the primary mechanism.

The case the old heuristic missed

According to the dev.to post, the evaluation adds a scenario to the public Signetry IPI corpus: a plan reads an untrusted README.md and then writes incident-report.md from env.SECRET, depending on that read. The v0.1 scan does not fire because the planted README contains none of the five hard-coded trigger phrases. The IFC engine denies the step on both axes — the write transitively inherits the README's UNTRUSTED label and carries a secret to a public sink.

The author states this is verified, not asserted: a named test re-runs the v0.1 scan over the materialized repo and confirms it detects nothing, which keeps the evaluation non-vacuous. The suite covers three scenarios — the two Signetry cases plus this secret-leak case — each with a test showing v0.1 would have let it through while the new engine does not.

An audit that caught a real bug

An independent audit using a fresh clone and a clean environment reproduced a genuine defect: the function assigning initial labels returned public-and-system for every read, so propagation through dependencies only worked via magic path prefixes baked into another function. The fix derives read labels from the path, and a regression test now fails if the bug returns. The audit also flagged a CI regression the fix caused — a bandit lint finding and a ruff formatting miss — both closed before merge.

What it does not do

The post is unusually direct about limits. The engine does not build the Plan itself; the caller must supply one, and there is no example integration with a real framework such as LangChain or an MCP harness — described as the largest gap between library and usable defense. Propagation follows declared dependencies rather than actual file contents, so a wrong declaration goes undetected in production. The evaluation corpus is three scenarios with fairly literal English attack text, with no evidence of resistance to phrasing variation, other languages or subtler attacks. Cross-iteration state remains a substring heuristic, with lattice-based persistence deferred to v0.3, and the code has never run against a real agent or production traffic.

On readiness, the post splits the question in two. Engineering hygiene is solid: consistent AGPL licensing with SPDX headers, CI that genuinely fails when something breaks, 23 non-vacuous tests, and an issues file that does not whitewash. As a turnkey product, it is not there yet. The highest-impact next steps listed are an example adapter for a real harness, an explicit threat-model document, a larger evaluation corpus and a quickstart separate from the API reference.

Why it matters

Coding agents routinely hold authority over deploy keys, CI configuration and secret stores while processing untrusted repository text and tool output. This prototype shows that classical information-flow control — integrity taints and confidentiality lattices — can catch escalation cases that keyword filters structurally cannot, because it never needs to inspect the attack text. Equally useful is the honest accounting of what separates a well-tested library from a deployable defense: until plan extraction from real agent runs exists, IFC enforcement stays something integrators must build themselves. For harness developers, the labelling scheme, its failure modes and the audit trail are worth studying even before the tool ships.