You know how a building's fire alarm system gets tested — not by setting actual fires, but by pulling one sensor offline at a time to confirm the rest still work? That is the core mechanism of Aletheia. It takes a coding agent's instruction file, translates every permission it requests into a typed formal language, then runs the agent's actual task repeatedly, each time revoking exactly one permission. If the task still passes all functional tests without that permission, you have a 'dispensability witness' — formal proof that the rule asked for more than it needed. And over-asking, in the context of AI agents that can touch your filesystem and network, is the signature of prompt injection. The committed claim: Aletheia is a permission-minimality testing framework that can detect prompt-injection attacks embedded in coding-agent instruction files by proving that specific requested permissions are unnecessary for the stated task. This is not the first paper to worry about prompt injection in LLM agents, but it is the first to formalize the detection problem as a permissions-dispensability problem with synthesized sandbox configurations and executable witnesses. The method works in three stages. First, Aletheia parses the instruction file and translates its authority requests into a typed permission language — think filesystem read/write, network access, credential use, data transfer. Second, it synthesizes sandbox configurations: one full-permission baseline and N independent restricted configurations, each removing exactly one permission. Third, it runs the unchanged rule and task under every configuration, comparing functional test outcomes. The key insight is that if a task completes correctly without a permission, that permission was not load-bearing — and a non-load-bearing request for credential access or data exfiltration is a red flag. The paper formalizes the synthesis procedure and proves the conditions under which dispensability witnesses imply enforceable restrictions. The evaluation is tight but narrow. On a shared refactoring task, Aletheia processes all 314 attack inputs from the AIShellJack dataset and flags every single one — 100% detection rate. Against five benign rule templates, zero false positives. Among 80 manually verified benign rules from GHAgentFiles, it raises three false alarms, yielding a 3.75% false-positive rate. These numbers are strong, but they come from a single task type (refactoring) and a single attack dataset. The paper is six pages with one figure, one table, one algorithm — compact and honest about scope, but the validation surface is small. The ladder context matters here. Prior work on prompt injection defense tends to fall into two buckets: input filtering (scan the prompt for suspicious patterns before execution) and output monitoring (watch what the agent does and kill suspicious actions). Aletheia occupies a third position — permission-boundary testing — which is structurally different because it doesn't need to recognize attack patterns or monitor runtime behavior. It tests whether the stated authority is minimal for the stated task. This sidesteps the arms race of pattern-matching against ever-evolving injection techniques. The closest prior art is the AIShellJack attack framework itself and general sandboxing approaches, but nobody has formalized the dispensability-witness methodology before. The integrity picture is mixed. The 314/314 detection rate is impressive but comes from a single attack corpus created by a known research group — we don't know how Aletheia performs against novel attack patterns that don't follow AIShellJack's structure. The 80 benign rules are manually verified, which is good, but 80 is a small sample for estimating false-positive rates with precision. The formalization is a strength: the paper provides actual proofs connecting witnesses to restrictions, which is more than most security papers offer. But there's no independent replication, no pre-registration, and the code availability is not explicitly stated. The milestone question is concrete: Aletheia works on one task type with one attack dataset. The next number to watch is whether it generalizes to diverse coding tasks — file I/O heavy tasks, API-calling agents, multi-step workflows — while maintaining that 100% detection rate and keeping false positives under 5%. If it can handle 10+ distinct task categories against 3+ independent attack corpora, this moves from proof-of-concept to deployable infrastructure. The gap is probably 1-2 years of community benchmarking. The obvious experiment not run: testing against adversarial attacks specifically designed to defeat permission-minimality testing — for instance, attack rules that request only permissions that ARE needed for the task but exploit them for dual use (the credential is needed for the API call AND for exfiltration). This is the hard case, and the paper doesn't address it. Honest read: this is likely (a) genuinely hard to construct a clean evaluation for, and (c) being saved for the follow-up paper that addresses the dual-use permission problem.
