Regent ControlOverview

Regent Control

Regent Control sits in the data path in front of an AI agent’s actions. Every tool call — a refund, a wire, a DB write, an API request — is authorized first (allow / deny / escalate), the real credential is injected by a sidecar so the agent never holds a key, and an immutable, attributable audit record is written.

Unlike an out-of-band token service, Regent Control is in-path — so it can enforce on transaction amount (mandates), redact sensitive response content, pause an action for human approval, and contain a hijacked agent. An authorizer that steps out of the path can’t.

How it works

  1. The agent points its tool calls at the sidecar (HTTP proxy /{tool}/{path} or MCP) — it holds no provider credentials.
  2. The sidecar asks the gate to authorize the call. The gate evaluates identity, mandate/spend limits, behavioral risk, and policy, and returns allow / deny / escalatedeny-by-default and fail-closed (any internal error denies).
  3. On allow, the sidecar injects the vaulted credential and makes the real call; on deny, the provider is never touched; on escalate, the action is parked for a human.

What you can enforce

CapabilityWhat it does
Policy (Cedar)allow / deny / escalate on role, operation, resource, amount, account facts
Mandatesspend caps — flat, per-entity (per customer/ticket), and relational (refund ≤ original charge)
Delegationverify the human’s OIDC token, derive the role, record “on behalf of”
Human-in-the-loopescalate to an approver; resume on approval
Provider authstatic bearer · OAuth2 · AWS SigV4 · mTLS — vaulted, the agent never sees it
Redactionmask sensitive fields/patterns in responses before the agent sees them
Audit + SIEMimmutable, anchored audit log + a real-time webhook to your SIEM
Containmentegress lockdown — a hijacked agent can reach nothing but the sidecar

Get started