Prevent

Prevent is the second move of the Trust Loop. Understand shows you why an agent decided what it did; Prevent decides whether the agent is allowed to act on it. A policy is evaluated at the decision point, against the reasoning of the run in flight, and it produces a verdict that is recorded on the run forever.

Policies gate the decision, not just the prompt

A keyword filter on the prompt cannot tell whether an action is safe, because the risk lives in what the agent decided to do, not in the words a user typed. AISquare policies evaluate the decision: the claims the agent made, the evidence it leaned on, the tool it is about to call, and the data crossing the boundary.

Each policy resolves to one of four outcomes:

• Allow. The action is within policy. It runs, and the pass is recorded.
• Deny. The action violates a blocking rule. It is blocked before it executes.
• Improve. The action violates an improving rule. The agent is handed a correction with a suggested fix and retries; repeated misses on the same rule escalate to a hard block.
• Warn. The action violates an advisory rule. It proceeds, and the run is flagged for review.

Policies do not fire in a vacuum. A rule can lean on what the reasoning and memory graph already holds: a refund already recorded against the order, a correction a reviewer made on a case like this one. That is Collective Intelligence powering enforcement, the same layer every capability writes into.

A verdict is the proof governance ran

Every run carries its verdicts: one row per policy check, each with the rule it evaluated, a pass or blocked result, a threshold meter showing the measured value against the limit, and a citation to the exact rule that fired. This is the concrete record that governance ran, not just that it was configured.

Reading these two verdicts from the same refund run:

• data-residency-eu passed. Every record the agent retrieved resolved to EU-hosted storage. The meter sits at 64 percent against an 80 percent ceiling, comfortably inside the limit, so the action ran and the pass is on the record.
• no-external-email blocked. The agent tried to send a confirmation email to an address outside the verified customer domain. That crossed the rule, so the tool call was stopped before it fired. The citation points at the exact rule, so the block is explainable to anyone who asks.

A blocked verdict is not a dead end. It is the signal that feeds Fix: a human can correct the decision in context, and the correction is carried forward by Remember so the same mistake is caught earlier next time.

Where the gate runs

Where a policy can enforce depends on how the agent is connected.

• The SDK runs the gate inside the agent, at the tool boundary, so a rule can block, improve, or warn on a tool call at runtime, before it fires.
• The proxy enforces at the LLM-call boundary, on AISquare's side. With the rule book in Live, a rule can block an unsafe tool call before it runs (the agent is handed the reason, so it re-plans a safe alternative), improve a non-compliant reply by rewriting it to comply, warn by flagging the run while it proceeds untouched, and gate-in by checking tool outputs for prompt injection and sanitizing them before the model sees them. See Proxy integration.

Rule books

Policies are grouped into a rule book: a named, versioned set of rules you sync to your workspace and attach to an agent. Because a rule book is versioned, a verdict can be traced to the exact rule text that was live when the decision was made, which is what makes an old decision defensible long after the rules have moved on.

Next steps