OpenAgentFlow puts the safety check at the moment before an action changes state

When the mail agent calls send(), the Action Plane on that path turns the call into an AgentEvent, and the Policy Enforcement Point evaluates it at what the paper calls the action-commit boundary, the moment immediately before the call alters user or enterprise state ^[8]. The evaluation is not confined to that one event. The PEP reads the accumulated session record: which agents have acted, what data they read, which external sources they contacted, and what they have already committed ^[10]. So a payload derived from an untrusted email three steps earlier is in view. A filter sitting inside the mail agent sees a well-formed send(), because per-action defenses are not designed to see across execution boundaries ^[4].

Enforcement covers exactly the paths the Action Plane sits on, which the dev.to write-up of the paper lists as GUI interactions, API calls, tool invocations and LLM-generated actions ^[6]. Any route to a state change that does not emit an AgentEvent is outside the control plane's view. Instrumenting a browser-driving agent so that every click emits an event is not an afternoon's work.

The pipeline has four tiers, and the write-up says most actions resolve at T1 or T2 without reaching the more expensive semantic evaluation at T3 ^[9]. That is a claim about the distribution of actions in the authors' test suites. For the latency behaviour to transfer, your action mix has to escalate to T3 at roughly the same rate, because the escalating share sets the average cost per committed action. The write-up defers full results to the paper and the TS-Bench benchmark ^[12].

On a 300-case controlled suite the authors report 94.00% accuracy and a 95.35% attack-block rate ^[12]. Ninety-four percent of 300 leaves 18 cases called wrong ^[14]. The block rate cannot be a fraction of 300, since 95.35% of 300 is 286.05; the only denominators at or below 300 that round to 95.35% are multiples of 43, so the attack subset was 43, 86, 129, 172, 215 or 258 cases, and between 2 and 12 attacks got through ^[15]. At the smallest of those denominators, one case is worth 2.33 percentage points ^[16].

For that block rate to say anything about a given fleet, the suite's composed attacks have to resemble the sessions actually being run: data crossing a trust boundary, then reaching a state-changing call several steps later. Prior research on indirect prompt injection has documented instructions hidden in consumed data redirecting agent behavior without touching the system prompt ^[13].

The design choice I would defend is the split itself, taken from OpenFlow and Ethane, which separated policy management from packet forwarding ^[5]. Policies, session state, audit evidence and provenance sit outside the agents, so a rule can be installed or updated after deployment without touching prompts, model weights or execution code ^[7]. When a new attack pattern appears, operators push a FlowRule and it applies across the whole fleet with no re-prompting and no retraining ^[11]. The write-up argues that this matters most where agent code is managed by multiple teams or third-party vendors ^[11].