Aletheia: Permission-Minimality Testing for Coding-Agent Rules

What it is

Aletheia is a permission-minimality testing framework for coding-agent instruction files (AGENTS.md, Cursor rules). It targets the specific case where a prompt-injected rule asks for credential access, file reads, or network egress that isn't needed for the task, while the agent still produces a correct patch — making functional correctness alone useless as a signal.

How it works

Aletheia translates each rule's requested authority into a typed permission language (SystemDSL), covering filesystem, network, tool, and sandbox grants, via an LLM emission step validated by an ANTLR4 parser and semantic checker. It then synthesizes sandbox configurations: one with full requested permissions, and one independent configuration per permission with that single grant removed (leave-one-out), using a dependency closure so that removing a permission doesn't silently leave access available through an overlapping grant (e.g., directory access covering a deleted file grant). Both the full and restricted executions run the same unchanged rule and task against independently authored tests, with state reset between branches via filesystem forks. If both executions pass the tests, and the restricted configuration strictly reduces enforced authority, that produces a "dispensability witness" — evidence the removed permission wasn't needed for this task. An LLM then interprets witnessed permissions against task context (actor, target, activation condition) before raising an alarm, since a legitimate optional operation can also be dispensable.

The execution backend uses Linux namespaces, private filesystem views, capability restrictions, and seccomp, with brokered communication enforcing network endpoint permissions (native tools can't open sockets directly).

Preconditions / Affected

Applies to coding agents that read repository instruction files and execute tasks with tool/network access. Requires independently specified tests not under attacker control, and trusted setup for baseline permissions — the rule's own claims of necessity are explicitly not trusted as authorization.

What to do

No remediation commands are given; this is a detection/testing methodology, not a patch. Teams building or auditing coding-agent pipelines could adopt the leave-one-out testing pattern: run tasks under full vs. incrementally restricted permissions and treat passing-under-restriction as a signal to investigate the removed grant.

Reported numbers: on GPT-5.5 via OpenRouter (4 workers, 8 agent turns/branch, 10s command timeout), full translation+execution took a median of 44.35 seconds and $0.22 per input. Of 80 real-world GHAgentFiles rules, 25 were unresolved (22 unsupported permission interpretations, 2 translation failures, 1 provider refusal) rather than confirmed negative — meaning roughly 31% of real inputs didn't get a clean verdict either way.

Caveats

The paper states its own limits plainly: witnesses establish task-relative dispensability, not malicious intent or a global minimum policy; attacks that misuse already-required authority yield no witness; the 80-rule benign set informed method development so it doesn't establish a population-level false-positive rate; and in an earlier internal comparison, task-context interpretation alone produced the same file-level alarms as the full execution-based criterion — meaning the paper itself notes the sandboxed execution step may not add classification power over interpretation alone, only tested evidence.