Archestra's OpenAPPA blocks agent exfiltration with data labels that only tighten

Archestra's documentation names the design it is arguing against. "The industry's answer to approval fatigue is a second model that judges each tool call: Claude Code's auto mode, Codex's auto-review, and other auto-modes," it says ^[4]. The objection is about what that judge is allowed to see. "Because classifiers are prompt-injectable themselves, harnesses hide tool outputs from them, so the judge never sees the data at all," the documentation says ^[5]. A judge shielded from tool output cannot know that the text it is approving for a public post came out of a private record ^[5].

The second objection is about rates. Even the best judges "top out at 99.3%," according to the documentation ^[6]. Taken at face value, the remaining 0.7% is 7,000 failures per million tool calls ^[1].

OpenAPPA turns the decision into a label comparison. Take an agent that reads a support ticket and then tries to post an update. The get_ticket_from_crm contract sets `delta = { audience = ["internal"] }`, so the run's audience narrows to internal when the ticket comes back ^[13]. The publish_update contract requires an audience that contains public ^[13]. An internal-only audience fails that test, and the call does not dispatch ^[2]. The web case runs on the trust axis: read_web_page marks its result suspicious, and apply_db_migration requires trusted ^[14]. An injected page can make whatever case it likes for the migration, and the engine, comparing labels from outside the loop, never reads the argument ^[16].

This is good engineering. A reviewer can work out what the agent may do by reading the TOML, and the answer is the same on every run ^[2]. Agents have beaten tool denylists by swapping a blocked rm -rf for an equivalent Python script ^[8]. A rule keyed on what the run has already read does not care what the next command is called, as long as the tool that executes it has a contract. I think this is the right design for any agent that reads private records and can also write to public endpoints.

Archestra's own documentation warns that rule sets "end up either so tight they break the agent or so intricate nobody can audit what they permit" ^[7]. Lattice composition keeps the labels consistent, and nothing in it limits how large or intricate an appa.toml can grow. When the labels block a flow that was legitimate, one way forward is an authority, which routes a single action to a human operator or an internal verification API for approval ^[15].

Bench-Corp, one of the two benchmarks in Archestra's runs, has 20 multi-step enterprise workflows ^[3]. InfoQ's account reports attack success only and does not give the number of attempts or a task-completion rate for any of the three systems. OpenAPPA's GitHub repository states the second half of the test itself: "Agent security has two axes: an agent that permits unauthorized flows is unsafe, and an agent that refuses valid work is useless" ^[9]. The 0% is a score on the first axis ^[3]. For it to transfer, another deployment would need tool policies at least as complete as the ones behind the benchmark runs, facing attacks of the same kind.