# OpenAgentFlow: How a Control-Plane Architecture Brings System-Wide Safety to Multi-Agent AI > Source: > Published: 2026-09-14 16:10:02+00:00 As AI agents move from isolated assistants into interconnected fleets that read emails, call APIs, browse the web, and modify databases, the safety problem changes shape. You can no longer protect a system by guarding a single model or a single tool call. A new paper — [OpenAgentFlow: Enabling System-Wide Safety Boundaries for Heterogeneous AI Agent Fleets](https://arxiv.org/abs/2609.00015) — proposes a concrete architectural answer, borrowing ideas from network engineering to govern agent actions at the system level rather than the model level. Modern agentic deployments rarely involve a single agent acting alone. A typical enterprise workflow might chain a planning agent, a web-browsing agent, a code-execution agent, and a mail-sending agent — each with its own runtime, its own tool set, and its own local safety checks. The trouble is that individually safe actions can combine into unsafe outcomes. Consider a scenario where an agent reads an email containing a hidden instruction (indirect prompt injection), then calls a payroll API, then sends a summary to an external address. Each step might pass a local safety check. The sequence, viewed as a whole, is a data exfiltration attack. This is what the OpenAgentFlow authors call **composed risk**: the danger that emerges from the interaction of actions across a session, not from any single action in isolation. Existing defenses — prompt-level filters, per-tool guardrails, agent-local runtime checks — are not designed to see across execution boundaries. They govern individual actions, not flows. Research on [indirect prompt injection](https://arxiv.org/abs/2302.12173) has documented this attack vector: malicious instructions hidden in data that agents consume can redirect agent behavior without touching the system prompt. As agents gain more autonomy, the attack surface for composed flows grows proportionally. OpenAgentFlow draws its design from network control-plane architectures like [OpenFlow](https://opennetworking.org/sdn-resources/openflow/) and Ethane, which separated policy management from packet forwarding. The same split applies here. **The Action Plane** sits on every execution path — GUI interactions, API calls, tool invocations, LLM-generated actions — and normalizes them into a unified `AgentEvent` stream. This normalization is the key move: regardless of whether an agent is clicking a button in a browser, calling a REST endpoint, or invoking a Python function, the resulting event looks the same to the enforcement layer. **The Control Plane** lives outside the agents entirely. It holds updatable policies (called `FlowRules`), session state, audit evidence, and provenance records. Because it is decoupled from the agents, administrators can install or update safety rules post-deployment without touching agent prompts, model weights, or execution code. Between the two planes sits the **Policy Enforcement Point (PEP)**, positioned at the "action-commit boundary" — the moment immediately before an action alters user or enterprise state. The PEP runs a four-tier evaluation pipeline: | Tier | Role | What It Does | |---|---|---| | T1 | Structured Rules | Explicit policy and scope checks; can terminate immediately | | T2 | Payload/Provenance | Pattern analysis and source-sink checks on the pending action | | T3 | Semantic Assessment | Local semantic check with escalation capability | | T4 | Final Adjudication | Last decision point before the action commits | The tiered design matters for latency. Most actions are resolved at T1 or T2 without reaching the more expensive semantic evaluation at T3. Only ambiguous or high-risk actions escalate to the full pipeline. The most technically interesting aspect of OpenAgentFlow is its use of **session-level provenance**. Rather than evaluating each action in isolation, the PEP has access to the accumulated state of the entire session: which agents have acted, what data they have read, what external sources they have contacted, and what actions they have already committed. This lets the system detect composed attacks that would be invisible to per-action filters. An agent reading an untrusted email is not inherently dangerous. An agent reading an untrusted email and then, three steps later, calling an external API with a payload derived from that email — that is a pattern the session-level view can catch. The provenance model also enables **policy evolution without agent modification**. When a new attack pattern is discovered, operators push a new `FlowRule` to the Control Plane. The rule takes effect immediately across the entire fleet, without re-prompting or retraining any agent. This is a meaningful operational advantage in environments where agent code is managed by multiple teams or third-party vendors. The authors evaluated OpenAgentFlow on three test suites, with full results reported in the [paper](https://arxiv.org/abs/2609.00015) and the [TS-Bench benchmark](https://arxiv.org/abs/2507.06134): The false-intervention rate — the fraction of safe actions incorrectly blocked — is worth watching. At 1.96% on the TS-Bench split, the system is precise enough for production without generating excessive friction for legitimate workflows. The authors also validated the architecture on live Android execution paths, governing actions across GUI, API, and LLM-planned channels simultaneously. If you are building or operating multi-agent systems today, OpenAgentFlow surfaces a few concrete design principles worth internalizing: **Treat the action-commit boundary as the governance nexus.** Prompt-level filters and model-level refusals are useful, but they operate before the agent has decided what to do. The action-commit boundary — the moment before a state change is written — is where you have the most information and the most leverage. **Normalize actions across execution paths.** The `AgentEvent` abstraction is simple but powerful. If your safety layer only understands API calls, it is blind to GUI actions. A unified event stream is a prerequisite for consistent enforcement. **Separate policy from execution.** Baking safety rules into agent prompts or model fine-tunes makes them hard to update and easy to bypass. A control plane that holds policies outside the agents lets you respond to new threats without touching the agents themselves. **Track session state, not just individual actions.** The composed-risk problem is fundamentally temporal. Safety systems that evaluate actions in isolation will always be vulnerable to multi-step attacks that distribute risk across a session. OpenAgentFlow is a research prototype, and several practical questions remain open. The paper does not address how the architecture handles very high-throughput agent fleets where the PEP could become a bottleneck. The four-tier pipeline adds latency, and the tradeoff between enforcement depth and response time will vary by use case. There is also the question of adversarial adaptation: attackers will probe for gaps in the `AgentEvent` normalization layer or attempt to manipulate session-state provenance directly. Still, the core insight — that multi-agent safety requires a system-level governance layer, not just per-agent guardrails — is well-argued and practically grounded. As agent fleets grow in complexity, architectures like OpenAgentFlow will likely become a standard part of the deployment stack. The paper is available at [arXiv:2609.00015](https://arxiv.org/abs/2609.00015), with evaluation details in the supplementary material. For broader context, the [AgentDojo benchmark paper](https://arxiv.org/abs/2406.13352) covers how prompt injection attacks are evaluated in multi-agent settings.