Onboarding Guide

The admin path to put Regent Control in front of an agent for one org. Everything below is configured under Control in the dashboard and published to the sidecar/gate within ~15s (no redeploy) — except the sidecar deploy + egress lockdown, which are one-time infra steps.

1. Bootstrap — keys, license, agent

The Control → Onboarding wizard issues these and hands you a ready .env / docker-compose for the sidecar.

2. Tools — the catalog

Each tool = a provider base-URL + how to authenticate. The catalog is the egress allowlist — the agent can only ever reach catalogued tools. Per tool:

• Auth type (the credential the sidecar injects — the agent never holds it):
  • Static — a vaulted bearer (secret_env).
  • OAuth2 — client-credentials: token endpoint + vaulted client id/secret env (+ scope). The sidecar fetches, caches, and refreshes the token.
  • SigV4 — AWS Signature V4 per-request signing (region/service + vaulted access/secret key env).
  • mTLS — a client certificate on the egress connection (vaulted cert/key paths).
• operation_map (optional) — derive a semantic op + resource_type so policy can say “deny delete on Contact” instead of matching a raw path.
• Mandate binding (optional) — attach a mandate_id + amount field so money calls run the spend check.
• Redaction (optional) — mask sensitive response fields/patterns before the agent sees them.

3. Policy — Cedar (allow / deny / escalate)

Author the org’s Cedar policy (a starter pack is provided). Policies match on the decision context — role, op, resource_type, amount, account_status. A forbid whose @id contains escalate maps to escalate (human approval) rather than a hard deny. Validate, then publish.

4. Mandates — spend control

• Flat — per-transaction / daily / monthly.
• Per-entity sub-budget — cap total spend per customer / ticket / vendor.
• Relational cap — bound an action (and the cumulative amount against the same reference) to a referenced anchor — e.g. a refund must not exceed the original charge.

5. Delegation — your IdP (on-behalf-of)

Point Regent at your IdP’s OIDC discovery/JWKS. When the agent forwards a human’s id_token, the gate verifies it and derives the principal + role itself (an asserted role is never trusted) — recorded as on_behalf_of. This lets policy say “a support_agent may refund ≤ $200.”

6. Enforcement mode

• observe — log what enforcement would do, allow everything (safe rollout).
• enforce — block on deny.

7. Human-in-the-loop — Approvals

When a policy returns escalate, the action is parked under Control → Approvals for a reviewer to approve/deny. The agent resumes on its next retry (same idempotency key). Optionally set an approver webhook so Slack/Teams/Telegram is pinged.

8. Audit export — SIEM/GRC

Forward every decision to your SIEM webhook (HMAC-signed), in addition to Regent’s durable, anchored audit log. Best-effort; never blocks a decision.

9. Deploy the sidecar

The sidecar runs next to the agent; the agent points its tool calls at it (HTTP proxy or MCP). Use the wizard’s compose, or the gate Helm chart for HA.

10. Hardening (optional)

• Open Hosts — the few hosts the agent may reach directly, bypassing the sidecar (e.g. the LLM endpoint). Admin-only; bypasses policy/audit/redaction, so non-regulated destinations only.
• Egress lockdown — init-container iptables so all other agent egress must traverse the sidecar. Turns “governs cooperative” into “contains hostile.” Apply on a canary first.

Verify