# Prevent (/docs/govern/prevent)

Prevent is the second move of the Trust Loop. [Understand](/docs/govern/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 [#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](/docs/collective-intelligence) powering enforcement,
the same layer every capability writes into.

## A verdict is the proof governance ran [#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.

<div className="liquid-glass my-6 p-5">
  <PolicyVerdict
    items="[
    {
      rule: 'data-residency-eu',
      status: 'pass',
      description: 'All retrieved records resolved to EU-hosted storage.',
      value: 0.64,
      threshold: 0.8,
      citation: 'data-residency-eu',
    },
    {
      rule: 'no-external-email',
      status: 'blocked',
      description:
        'Step attempted to email an address outside the verified customer domain.',
      value: 0.97,
      threshold: 0.5,
      citation: 'no-external-email',
    },
  ]"
  />
</div>

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](/docs/govern/fix): a human can correct the decision in context, and the
correction is carried forward by [Remember](/docs/govern/remember) so the same
mistake is caught earlier next time.

## Where the gate runs [#where-the-gate-runs]

Where a policy can enforce depends on how the agent is
[connected](/docs/govern/connect-your-agents).

* 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](/docs/govern/proxy-integration).

<Callout intent="warning" title="Start in Audit, then go Live">
  Each workspace has a Live / Audit switch. **Audit** records and flags but never
  alters a run; start there to see what your rule book would do. **Live** applies
  enforcement in real time. Both connection paths give you full policy
  visibility either way: every run is scored against your rule book and every
  verdict is recorded.
</Callout>

## Rule books [#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 [#next-steps]

<Cards>
  <Card title="Fix" href="/docs/govern/fix" description="Correct a blocked or wrong decision in context, and keep the correction." />

  <Card title="Remember" href="/docs/govern/remember" description="Carry decisions and corrections forward as enterprise memory." />

  <Card title="Understand" href="/docs/govern/understand" description="The reasoning a policy is evaluated against." />

  <Card title="Errors" href="/docs/reference/errors" description="How the API surfaces blocked and escalated actions." />
</Cards>