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. AISquare evaluates each policy at the decision point, against the reasoning of the run in flight, and records the verdict 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 row shows the rule evaluated, a pass or blocked result, a threshold meter with 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.

Read verdicts over the API

The verdict card above is a JSON document first. Every run's per-rule verdicts are one read, so a CI job, a compliance report, or a coding agent can prove governance ran, and see exactly which rule fired, without opening the dashboard. Setup (gateway URL, studio key, studio id) is the same as in Understand.

curl -s -H "X-API-KEY: $EXPLAINABILITY_API_KEY" \
  "$EXPLAINABILITY_GATEWAY_URL/v1/studios/$STUDIO_ID/runs/$RUN_ID/policies"

{
  "aisquare_rule_book_audit": {
    "status": "ok",
    "engine": "rule-book-llm-judge-v1",
    "aisquare_verdict": {
      "decision": "block",
      "passed_count": 1,
      "failed_count": 1,
      "gates": [
        {
          "gate": "src:no-external-email",
          "name": "No external email",
          "passed": false,
          "triggered": true,
          "detail": "attempted to email an address outside the verified customer domain"
        }
      ]
    }
  }
}

Read each gate the way the dashboard does: passed: false is a fail, passed: true, triggered: true is a pass, and passed: true, triggered: false means the rule did not apply to this run. The detail string is the judge's own reasoning in plain language, which makes it the single most useful field for an agent trying to correct itself.

Verdict response fields (all under aisquare_rule_book_audit):

The call takes no query parameters; studio_id and run_id in the path are all it needs.

Two companion reads round out the proof:

curl -s -H "X-API-KEY: $EXPLAINABILITY_API_KEY" \
  "$EXPLAINABILITY_GATEWAY_URL/v1/studios/$STUDIO_ID/runs/$RUN_ID/rule-book"
curl -s -H "X-API-KEY: $EXPLAINABILITY_API_KEY" \
  "$EXPLAINABILITY_GATEWAY_URL/v1/studios/$STUDIO_ID/policy/compliance"

rule-book names the book, its version, and the engine, so a verdict can be traced to the exact rule text that was live when the decision was made. compliance summarizes the last 7 days: the compliance percentage, run and violation counts, and the most-violated policies. The window is fixed; neither call takes query parameters.

A blocked verdict read over the API is the same signal the dashboard shows, and it feeds Fix, where the correction is also an API call.

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 take four actions. block withholds an unsafe tool call; the agent gets the reason and re-plans. improve rewrites a non-compliant reply to comply. warn flags the run while it proceeds untouched. gate-in checks tool outputs for prompt injection and sanitizes 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. A rule book is versioned, so every verdict traces to the exact rule text in force when the decision was made. That is what keeps an old decision defensible after the rules move on.

Next steps