Pre-Action Gates for AI Agents: A Practical Enforcement Contract

Most agent stacks can tell you what happened after a tool call. Fewer can stop a dangerous call before it executes.

That distinction matters once an AI agent can run shell commands, edit files, operate a browser, trigger deployments, or call external APIs. A trace explains an incident. A pre-action gate prevents one.

The enforcement boundary

A useful gateway sits between model intent and tool execution:

model proposes action
        ↓
pre-action policy evaluates context
        ↓
allow | block | require approval
        ↓
tool executes only when permitted

The gate should not replace the model or orchestration framework. It should make one narrow decision using concrete execution context.

A minimal decision contract

A proposed action can be represented with a small payload:

{
  "actor": "coding-agent/session-42",
  "tool": "shell",
  "arguments": ["git", "push", "--force", "origin", "main"],
  "resource": "repository:production",
  "approval": null,
  "context": {
    "branch": "main",
    "environment": "production"
  }
}

The policy response is equally small:

{
  "decision": "block",
  "rule": "protected-branch-history-rewrite",
  "evidence": "Force-push targets protected branch main"
}

This is an infrastructure-firewall pattern: deterministic enforcement at the point where a probabilistic system is about to create a real side effect.

What belongs in the policy context?

At minimum:

1. Actor identity — which agent, user, or service initiated the action?
2. Tool and exact arguments — what will execute, not just the model's summary.
3. Resource scope — which repository, file, account, database, or browser surface changes?
4. Environment — local, staging, or production?
5. Approval state — is there a valid bounded approval for this action?
6. Prior failure rules — has the operator already corrected this pattern?

The last item is critical. If an operator says “never rewrite the protected branch again,” that correction should become a prevention rule, not a note the model may forget.

Memory is not enforcement

A vector database, conversation history, or repository instruction can remind an agent about prior failures. It cannot guarantee that the next tool call complies.

A durable feedback loop needs to:

1. capture a specific success or failure signal;
2. reject vague signals that cannot become rules;
3. promote repeated or severe failures;
4. evaluate promoted rules before tool execution;
5. preserve decision evidence for audit and debugging.

This turns “the agent apologized” into “the agent cannot repeat the same action.”

Start with high-consequence actions

Do not gate every harmless read. Begin where errors are expensive or irreversible:

• protected-branch writes;
• production data mutations;
• credential-bearing output;
• external messages and publications;
• releases and deployments;
• destructive filesystem operations;
• dynamic tool creation and privileged browser interaction.

The objective is not maximum blocking. Measure whether known failures are prevented while legitimate workflows still finish.

Operational metrics that matter

Policy count is a vanity metric. Better questions are:

• Which actions were blocked?
• Which actions required approval?
• Did the same failure recur?
• What is the false-positive rate?
• Can critical workflows complete without bypassing the gateway?
• Is every decision backed by inspectable evidence?

Reliable autonomy means increasing agent capability without asking operators to trust every tool call blindly.

ThumbGate implements this pre-action Reliability Gateway pattern for AI coding and operations agents.

Evaluate your own workflow

Run the Agent Reliability Diagnostic

Start with ThumbGate Pro