Bounded Action Firewall and Action Gate Leases
A runtime enforcement primitive for making human approval non-transferable: valid only for the canonical action, actor, session, policy, destination, proof receipt, and time window it was issued for.
A runtime enforcement primitive for making human approval non-transferable: valid only for the canonical action, actor, session, policy, destination, proof receipt, and time window it was issued for.
BAF, short for Bounded Action Firewall, is the runtime enforcement layer that sits after action analysis and before execution.
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.
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. If the canonical action fingerprint, actor, session, policy version, destination scope, proof receipt, dissent state, or exception state changes, the old approval should not silently travel with it.
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. |
CAVA creates the canonical action object. Policy and Decision Score route the action. PCAA decides who has authority to approve it. BAF enforces the boundary around that approval.
The invariant is simple: if the consequence changes, the approval no longer applies.
That invariant is what turns a human click into an enforceable control. The customer can approve a risky action without granting the agent a broad permission that silently survives context drift.
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.
Request enterprise access and send your first governed decision today.