What is Pre-Action Gate?

Why It Matters

The pre-action gate is the only enforcement point that prevents rather than detects. Every control after it deals with an action already in flight or already done; the gate is where a bad action becomes a denied proposal instead of an incident. The PocketOS incident is the canonical case: a coding agent wiped a production database in nine seconds. A gate checking the target environment against the agent’s authorized scope would have denied the volume-deletion mutation before it ran. No confirmation prompt, no dry-run mode, and no clicking through: the gate replaces the confirmation prompt entirely.

The Three Decisions

Allow. The tool runs. The action matched policy, the scope is within bounds, and the target is on the allowlist.

Deny. The tool never runs. The agent receives a structured rejection carrying the policy reason, so it can plan around the denial instead of retrying blindly.

Escalate. The action pauses and routes to a human reviewer, because the case sits in a gray zone where policy is ambiguous or the risk profile requires judgment.

Where It Breaks

Placement is the first failure. A gate implemented as a tool description or a prompt instruction sits inside the model’s view, and anything the agent can reason about it can reason around. The second failure is scope drift: the gate checks that a mutation is allowed but not that this agent, in this environment, on this resource, is allowed to run it. That is the check that would have stopped PocketOS, and it is the one most implementations skip.

How Flytebit Handles It

Every tool call in the systems we ship passes a pre-action gate that evaluates the action, the agent’s identity, the environment, and the resource scope before execution, with denials returned as structured rejections the agent can route around. The gate is one of four enforcement points covered in Governing Agentic AI, and the engagement version is our AI governance and risk work.