{
  "id": 4134643,
  "title": "agent-harness-defense v0.2.0: dual-lattice IFC for LLM agent privilege escalation",
  "url": "https://urgent.news/2026/08/29/agent-harness-defense-v0-2-0-dual-lattice-ifc-for-llm-agent-privilege",
  "topic": "ai",
  "section": "AI",
  "published": "2026-08-29T07:23:28.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/magopredator/agent-harness-defense-v020-dual-lattice-ifc-for-llm-agent-privilege-escalation-46jh"
  },
  "original_language": "en",
  "account": "Agent-harness-defense version 0.2.0 introduces a dual-lattice information-flow control (IFC) for LLM agent privilege escalation prevention. This open, offline-verifiable admission layer addresses two structural gaps in the literature: instruction privilege escalation and non-decaying loop state. The admission layer enforces a plan-first information-flow policy by requiring explicit descriptions of an agent's proposed actions before execution. Before a change is applied, run_admission() is called with the explicit description, and it returns a verdict - admit, deny, and the reason for the decision. The decision core of the system is the dual-lattice IFC engine, which applies componentwise lattice join over the depends_on graph to evaluate the plan. Confidentiality is determined by the max operation, ensuring the result is as sensitive as the most sensitive operand, while Integrity is determined by the min operation, preventing the no-upgrade rule. The engine labels each datum in the plan with two labels: Confidentiality and Integrity. Reads are classified by their path, and writes that depend on untrusted reads are denied, while writes sourced from env.SECRET to public sinks are also denied. The dual-lattice IFC denies the step on both axes (integrity and confidentiality) when the write inherits the README's UNTRUSTED label and carries a SECRET to a public sink. The evaluation corpus covers three scenarios, including the Signetry IPI scenarios (README injection and CLAUDE.md scope expansion) and an own secret-leak scenario. Each scenario has a test proving v0.1 would have let the escalation through, and the new engine does not. The audit also caught a bug where _step_initial_label returned (PUBLIC, SYSTEM) for every read, leading to incorrect propagation through depends_on. The fix derived the read label from the path, and regression tests confirmed the bug was resolved. However, the library does not extract the plan itself and requires the caller to supply the explicit plan. Integration with real LLM frameworks is on the user, and there is no evidence of resistance to phrasing variation, other languages, or subtler attacks. The roadmap calls for v0.3, but the current version is still limited in its scope compared to a fully integrated defense.",
  "summary": "agent-harness-defense v0.2.0: dual-lattice IFC for LLM agent privilege escalation An open, offline-verifiable admission layer that stops instruction-privilege escalation in coding agents by enforcing a plan-first information-flow policy. A research prototype with a rigorous audit — not a turnkey production defense. The problem LLM coding agents run over untrusted web pages, docs and tool output…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}