Guardian Agents

Governance that runs where your agents run

Guardian Agents run inside your stack through the HAI Guardian SDK. They watch what your AI says and control what it does in real time, without changing how your teams build.

Full Claude Code hook coverage No agents to install Any model provider
SentinelWhat it says
OperativeWhat it does
ThresholdBlocked inline

You wrote the policy. The agent never read it.

Policy on paper

§4.2 Agents must not read secrets or run destructive commands. Spend is capped per session. Every action is logged.

A control that lives in a document can't stop anything.
Enforcement
gap

Agent in runtime

read_file · config.yamlALLOW
exec · rm -rf /BLOCK
access · .env secretBLOCK
tool · search_docsALLOW

Guardian closes that gap. Your controls stop being words in a document and become live rules that sit inside the agent's harness. They get checked on every action and enforced the moment risk crosses the line.

How Guardian Agents work

From control to enforcement, in one runtime loop

You wrote the policy, but the agent never read it. Guardian Agents turn your controls into live rules that live inside the agent's harness. Every action is checked, enforced and logged in one trail you can audit.

Stage 01 · Controls

Define your controls

Set warn and block thresholds for every Guardian control. Decide what your AI is allowed to say with Sentinel and what it's allowed to do with Operative. Start from a ready-made library that already maps to the frameworks you report against.

  • Out-of-the-box control library
  • Mapped to EU AI Act, NIST AI RMF, ISO 42001
  • Add your own custom controls
HAI Guardian SDK
Claude Code OpenAI SDK LangGraph AutoGen
Stage 02 · Integrate

Drop in one SDK

Guardian runs through a single SDK. There are no agents to install and nothing changes in how your teams build. The same integration powers both monitoring and enforcement, right inside the harness your agents already run in.

  • One SDK for observe and enforce
  • Full Claude Code hook coverage today
  • Any framework, any model provider
HOOK
ALLOW WARN BLOCK
Stage 03 · Enforce

Enforce at runtime

Every prompt, response and tool call gets a score from 0 to 1 inside the harness, before anything runs. Below the line Guardian warns and logs it. Above the line it blocks the action on the spot, and the agent has no way to reason around it.

  • One 0–1 warn / block threshold
  • Blocks the action inline, in real time
  • Deterministic and enforced in the harness
ALLOWtool call · read_file0.08
WARNsensitive data · PII0.61
ALLOWpre-hook · prompt0.12
BLOCKtool call · rm -rf /0.97
BLOCKaccess · .env secret0.93
Stage 04 · Observe

Observe and prove it

Every warning and block lands in one incident log and one tamper-evident audit trail. You get a continuous record of everything your agents say and do. Query it, set alerts on it, and show regulators exactly what governance did.

  • One incident log across say and do
  • Tamper-evident audit trail
  • Live enforcement telemetry
One threshold model, one incident log, one audit trail, and one SDK behind every stage.
Two agents, one model

Sentinel watches what your AI says.
Operative governs what it does.

Both run through the same SDK, share one threshold, and write to the same incident log. The only difference is whether they watch or act.

Sentinel Agents
Watch · Detect · Alert
What your AI says · content safety

Sentinel keeps an eye on model and agent output in production. It catches unsafe, leaking or off-policy behaviour without getting in the way of the workflow.

Sentinels give you visibility. They tell you what is happening without stepping in.

Operative Agents
Act · Intervene · Enforce
What your AI does · runtime enforcement

When risk crosses the threshold, Operative steps in. It governs which tools an agent can call, what it can reach, and how much it can spend, all in real time.

Operatives turn governance into action.

Runtime enforcement · Operative

The controls that stop an agent mid-action

Runtime monitoring enforces what an agent is actually allowed to do. It happens before the call runs, not after the fact in an audit.

Tool Calling Access

Decide which tools an agent can invoke, then stop the call before it runs.

  • Allowlist & blocklist per tool
  • Blocked commands like rm -rf /
  • Enforced pre-execution, in the harness

Access Control

Gate exactly what an agent can reach across your environment.

  • Files, directories & databases
  • Environment variables & secrets
  • Customer PII

Cost Control

Keep autonomous spend attributed, capped and auto-contained.

  • Spend attribution per session, team & tool
  • Per-minute rate limits
  • Abnormal-usage auto-cutoff

Agent Identity

Every agent runs under a known identity, so each action is attributable and every control resolves against who is acting.

Custom Controls

Encode your own rules on the same threshold model. It stays your policy, enforced with the same warn and block mechanics.

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.