The Provisioning Workspace

Everything you enroll starts at Provisioning (in the sidebar). The workspace shows your current governance reach, a coverage summary across surfaces, and a menu of enrollment methods — each a card with a one-click action.

Provisioning — governance reach, coverage stat row, and the eight enrollment-method cards.

The stat row at the top tracks Enrolled Agents, MCP Servers, SaaS Connectors, Browser Deployments, Coverage, Pending, Coverage Gaps, and Last Enrollment. Below it, the enrollment methods:

Enrollment method	What it governs
Agent Enrollment	Bind an autonomous agent to its identity — Python / TypeScript SDK, a custom MCP client, ChatGPT, or Open Interpreter.
IDE & CLI Enrollment	Connect a developer tool — Claude Code, Cursor, VS Code, Windsurf, Warp, Zed, Codex CLI, Claude Desktop — by auto-wiring its MCP config.
Browser Extension	Deploy the browser extension via MDM to capture Claude / ChatGPT / Gemini browser traffic.
MCP Server Registration	Register an MCP server (HTTP or stdio); Behavry inserts itself between agent and target.
SaaS Connector Activation	OAuth into Slack AI, GitHub Copilot, or Salesforce Einstein to observe, redact, and gate vendor AI.
Enforcement Proxy	Route model traffic through Behavry's inline enforcement layer — no SDK changes.
Behavry Wardens	Deploy the desktop agent (Windows / macOS) for OS-level coverage of all AI traffic.
Mobile Deployment	iOS Safari / Android WebView coverage — coming soon.

Choose least-privilege roles up front

Every method issues an identity plus the roles you assign. Assign the narrowest role set that lets the agent do its job. You can widen later; starting wide is hard to walk back. See Agent Roles.

The Behavry Wardens drawer

Opening the Behavry Wardens card gives you the fleet: enrolled devices, their liveness, the collection grants that govern what they report — and the set of AI providers they intercept.

AI provider coverage

Wardens carry a provider registry compiled into the binary. Covering a newly-discovered provider used to mean cutting a signed agent build and rolling it to every endpoint, or hand-editing config on each machine. Providers appear faster than either of those happens, and in that window the traffic was not merely unenforced — it was invisible.

Providers added here are served on the policy channel. The device already polls that channel every five minutes, so a provider you add is routed and inspected fleet-wide on the next refresh: nothing installed, nothing restarted, no re-enrollment.

The AI providers control, directly below the collection grants that govern it.

The compiled registry is a floor, not a default

An empty list, an unreachable backend, and a response that lost the field all resolve to "the providers this binary shipped with", never to none. Narrowing coverage fleet-wide must not be something a server outage can do by accident.

API endpoints and chat UIs are separate

Entries keep the split rather than collapsing into one host list, because the tenant's web-UI interception grant governs only the second — and the providers an organization learns about after deployment are disproportionately consumer chat UIs.

A flat list would have made the mechanism for adding a provider also the mechanism for decrypting someone's browser session, without the authorization that decision requires. A pushed chat UI is routed but stays undecrypted until the grant is on, exactly like one the agent shipped with. Chat-UI rows are marked distinctly in the drawer because they behave differently.

Breadth is bounded

This screen is the easiest place in the product to accidentally point every Warden at everything. Typing .amazonaws.com instead of bedrock-runtime.*.amazonaws.com would route and decrypt every S3 and SQS call on every enrolled laptop.

So a host must carry at least three fixed labels behind a whole-label wildcard, or be a suffix match:

Entry	Accepted	Why
bedrock-runtime.*.amazonaws.com	Yes	One product, every region
.openai.azure.com	Yes	One product
.googleapis.com	No	That is a cloud, not a provider
.amazonaws.com	No	Same

Schemes, ports, paths, and bare TLDs are refused, as is a host already claimed by another provider — which would make event attribution depend on list order. A rejection is surfaced verbatim with your typed host kept in the field, so you can correct it rather than retype it out of an error message.

Adding a provider is audited like a collection grant

It widens what is inspected on real people's machines, so the write records before-and-after state with the administrator's identity, and requires read-write authority on policies — not merely being an admin.

Coverage numbers will move

Two long-standing gaps were closed in the same pass, and both were silent — the device stayed healthy and the fleet view stayed clean while traffic went uninspected:

• AWS Bedrock was uninspected on every device. The registry entry named a host AWS does not serve (bedrock-runtime.amazonaws.com; inference is only ever regional), so it matched nothing anywhere while sitting in the supported-provider list. The same class of miss covered Vertex AI, GitHub Copilot's per-plan hosts, and Cursor's api2/api3. xAI was absent entirely.
• WebSocket connections to a monitored provider never completed. Neither side of the exchange moved, and because nothing returned an error the per-host circuit breaker never counted a failure. Upgrades are now relayed rather than forwarded; the session is reported as an event and its contents are not inspected.

When devices take the current build, previously invisible providers start reporting. That is a real finding for whoever reads the numbers, not a regression.