Guardian is Regent’s ML layer. It watches every agent’s audit stream in real time and produces a risk score between 0 (normal) and 1 (highly anomalous). When the score crosses a configured threshold an alert is created — and the gate can deny a high-risk action even when every individual rule passes.

Why ML, not just rules

Mandate enforcement (per-tx limits, daily caps) is rule-based and deterministic — it catches known violations. Guardian catches the unknown ones: agents whose individual actions are all within limits but whose pattern is suspicious.

Examples Guardian catches that mandates miss:

• An agent suddenly making many tiny trades after weeks of normal pacing
• An agent triggering many rejections in a short window (probing limits)
• An agent active at an unusual time of day for its profile
• An agent whose action types shift dramatically (e.g., started buying, now only selling)

How scoring works

Every audit event triggers a fresh score for that agent. Guardian derives behavioral signals from the agent’s recent activity, evaluates them with an unsupervised anomaly-detection model, and emits a risk score together with a set of explanatory factors. Scoring runs in-line with audit ingestion and is fast enough to inform authorization in real time.

Explainable by design

Every score comes with per-signal contributing factors — so an alert can be defended with a concrete attribution rather than “the model said so.” This supports the EU AI Act’s explainability expectations: each alert carries a human-readable reason for why the behavior was flagged.

Alerts

When a score crosses the alert threshold (configurable per environment), Guardian creates an alert with status open, surfaced on the dashboard; operators acknowledge or resolve it via the API. A separate drift signal flags a sudden jump in an agent’s score between consecutive events.

A second layer of denial

When api-payment authorizes an action, it consults Guardian’s latest score as a soft dependency: if Guardian is unavailable, authorization still proceeds. If the score is high enough, the action is denied with RISK_THRESHOLD_EXCEEDED — so an agent whose behavioral risk has spiked is blocked even when its individual action is within the rulebook.

The behavioural layer in the gate

Guardian’s score is one input. The gate also computes two deterministic signals per decision, in the request path, from its own counters:

• Velocity — how many decisions this agent asked for in the last minute and hour, allowed or refused. The starter policy escalates at 60 per minute (context.velocity_1m); an organization’s own Cedar policy can escalate or deny at any figure.
• Near-duplicate — a money request identical to one allowed in the last 60 seconds (same canonical request hash) with no idempotency_key. The starter policy escalates it (context.duplicate). A request that carries an idempotency_key is a deliberate repeat and is never flagged; a voided or failed earlier attempt reopens the window so a retry is not flagged either.

Both signals are recorded in the audit event (velocity_1m, velocity_1h, duplicate_of) and never in tokens or receipts. Refusals surface as VELOCITY_EXCEEDED / DUPLICATE_REQUEST when a policy forbids, or as ESCALATION_REQUIRED when it asks for a human.

Related