Restricted Mode
Restricted Mode is included on the Professional and Enterprise plans.
What this is
Behavry has three traditional enforcement modes — report-only (log and continue), circuit-breaker (halt on anomaly, resume when clear), and hard-block (deny on policy match). Restricted Mode is a fourth: the agent keeps running, but with a reduced tool surface and policy-dictated fallbacks.
The use case is the gray zone between "everything is fine" and "shut this agent down." You noticed unusual behavior, but you don't want to page a human — you want the agent to finish its current task with training wheels on.
How it works
Restricted Mode is a per-agent (or per-session) state flag evaluated early in the proxy pipeline (backend/behavry/proxy/restriction.py). When an agent is in Restricted Mode, every tool call goes through a 7-stage evaluation:
- Policy check — is the tool on the restricted profile's allow-list?
- Scope check — does the target fall inside the profile's allowed scope (path prefix, domain list, table list)?
- Argument check — are the tool arguments within the profile's argument bounds (size, count, enum values)?
- Rate check — is the agent still inside the profile's per-tool rate limit?
- Fallback check — if blocked, is there a profile-defined fallback tool or response?
- Audit — write a
restriction.checkedevent regardless of outcome - Dispatch — allow, fallback, or deny
Stages 1–4 are short-circuit: the first failure decides the outcome. Stage 5 is the differentiator — instead of a flat deny, the profile can substitute a safer tool (e.g. read_file instead of write_file) or a canned error message.
Built-in profiles
Three ready-to-use profiles ship with the product:
| Profile | When to use | Typical effect |
|---|---|---|
investigation | Suspected anomaly, want to keep running while a human reviews | Read-only tools allowed, writes fall back to a "pretend success" response, rate limits tightened 2× |
wind_down | Scheduled deactivation, finish current task and stop | Only complete, return, and exit tools allowed; everything else denied |
containment | Confirmed compromise, maximum restriction without full kill | Only audit, status, ping tools; every other call denied with a containment notice |
Profiles are defined as Rego policies under policies/restricted/ and can be cloned and customized per tenant.
Entering Restricted Mode
Three paths put an agent into Restricted Mode:
- Manual — Agents → (agent) → Restrict in the dashboard, pick a profile, optional expiry
- Automatic — a behavioral alert or red-team finding triggers a policy that escalates to restriction instead of a hard-block
- Scheduled — a cron-style policy switches an agent into
wind_downon a schedule (e.g. end of shift)
Entry and exit write restriction.entered / restriction.exited events with the profile, source, and operator (for manual actions).
API
Routes: backend/behavry/admin/restriction_routes.py.
| Method | Path | Purpose |
|---|---|---|
GET | /api/v1/restrictions | List active restrictions tenant-wide |
POST | /api/v1/agents/{id}/restrict | Enter Restricted Mode with a profile |
DELETE | /api/v1/agents/{id}/restrict | Exit Restricted Mode |
GET | /api/v1/restriction-profiles | List available profiles |
POST | /api/v1/restriction-profiles | Create a custom profile |
Interaction with other features
- Blast Radius Limits — still enforced, on top of the restricted profile. The stricter wins.
- Context Gate — the filtered tool list is recomputed when Restricted Mode changes; the agent immediately sees fewer tools.
- HITL Escalations — fallbacks produce lower-priority "informational" escalations so operators can watch behavior without drowning in pages.