BAF, short for Bounded Action Firewall, is the runtime enforcement layer that sits after action analysis and before execution.
Research update: 5 October 2026. This working research direction for connecting BAF and AREG is unpublished and not peer-reviewed. This entry retains its original June publication date and distinguishes current checks from the proposed connection.
The problem is approval reuse. Once a human approves an agent action, many systems treat that approval as a general yes. That is unsafe for agentic runtimes because the surrounding context can change quickly: command text can drift, the destination can change, the session can rotate, the policy version can update, or the agent can retry in a different lane.
BAF turns that approval into an Action Gate Lease.
Interoperability does not make approval reusable
Agent interoperability protocols help agents discover tools, call services, delegate work, and exchange messages. They should be treated as useful runtime lanes, not as approval semantics. A well-formed MCP or A2A exchange can still carry an action whose consequence has changed, whose destination widened, or whose exception was never authorized.
BAF exists because the approval boundary must be stricter than the protocol boundary. A changed canonical action fingerprint, actor, session, policy version, proof receipt, dissent state, or exception state must not silently inherit the old approval. Destination changes require a containment check, not an assumption that every change is either safe or forbidden.
What the lease binds
An Action Gate Lease is intentionally narrow. It is valid only for the action and context it was issued for.
| Binding field | Reason |
|---|---|
| canonical action fingerprint | Approval binds to action meaning, not mutable UI text. |
| policy version | Approval cannot cross into a different governance rule set. |
| actor identity | Approval cannot transfer from one agent, user, or service account to another. |
| runtime session id | Approval cannot be reused by a different runtime session. |
| destination scope | Approval cannot drift to a different branch, endpoint, customer, system, or account. |
| approval TTL | Approval expires instead of becoming an indefinite permission. |
| proof receipt digest | The final decision can be replayed and exported. |
Current strict context and effect matching
The current strict matcher in cava-core's execution-boundary.js compares artifact, configuration, and dependency commitments. It requires one coupled operation, effect, resource, and destination tuple, including parameter constraints, to match the observation supplied by a trusted executor. Matching fields from separate authorized tuples cannot be combined into a new permission.
Missing context or incomplete evidence requires review without dispatch. Context drift and effects outside the declared boundary are denied. The pure matcher does not authenticate collectors, inspect binaries, or intercept unmediated effects. A source label or completeness flag is a trusted integration input, not proof that capture is truthful or complete.
Signed admission also depends on the bound issuer, holder/session, policy and state, validity window, current authority, and durable consumption state. Passing the tuple matcher alone is not permission to execute.
How it fits OSuite
PCAA supplies final governance authority. CAVA supplies canonical action identity. BAF enforces bounded authorization. AREG supplies exposure evidence and uncertainty. Policy and Decision Score route the action within that authority model; an exposure prediction cannot replace it.
A proposed connection would use AREG evidence to describe state-dependent reachable consequences and inform BAF lease validation. This is not an implemented complete future-program closure predictor. The current AREG bounds operate only over a finite set of supplied occurrences and declared worlds; they do not discover every future action a program can cause. Prediction never grants permission.
An unrelated graph change is not automatically an authorization violation. Safe narrowing is conditional on action identity, lifecycle, authority, and freshness, as well as containment within the declared context and effect vocabulary. A failed proof of narrowing is not itself proof of widening; an unresolved comparison needs review, not silent reuse or an invented violation.
If a relevant context commitment changes, the strict equality check still rejects it. If a candidate effect widens beyond the authorized boundary, the old lease does not cover it. A narrower effect cannot restore an expired, revoked, consumed, or otherwise invalid lease.
Prevention requires a mediated commitment boundary
Every covered side effect must be mediated before commitment, including descendant work reached through scripts, tools, SaaS calls, or nested agents. An admission check cannot prevent a later unmediated effect or close a race between validation and receiver commitment. Those guarantees require trusted effect capture and a final enforcement boundary for the covered operation. Post hoc detection is not prevention.
ZeroGate avoids redundant analysis by preparing an Action Pass earlier, while retaining live revocation checks and durable consumption at admission. That preparation does not remove the need to validate current authority and the actual execution boundary. This update makes no new performance claim; the ZeroGate reading link above provides the existing measurements and their scope.
Related work and scope
Zhang et al., Section VII already describe the Bind-Enforce-Contain principle, richer labels, and applicability to SaaS and nested-agent settings. Their closure-bound approval relation supports effect descriptions beyond the initial invocation.
Formation-Consistent Dispatch (FCD) already addresses typed effects, formation-scoped authority, lifecycle controls, and a final fence connecting the admitted target to execution. These mechanisms provide related-work context for the working proposal.
What customers see
In product language, BAF answers a question security teams immediately understand: can this approval be reused?
OSuite can show whether an action is lease-ready, approval-bound, fail-closed, observe-only, expired, unsigned, or unbound. That gives operators a concrete path between human review and runtime enforcement.
BAF is not meant to be a separate product the customer has to configure from scratch. It is the firewall behavior inside the governed action path.
