Enforcement
The agent policy is advisory today; nothing is blocked automatically.
It's worth being precise about what the agent policy actually does, because it's less than the name might suggest.
Today, the agent policy is flag-only. It never blocks a session from starting, a workspace from launching, or a model call from going through.
What happens when someone doesn't match the policy
Nothing happens automatically. The member keeps working exactly as before. The only effect is that their selection shows up in the Conflicts table on the Agent policy screen, listed by name, coding agent, surface (cloud or local), and the route they're actually using.
Agent policy conflicts table
Organization settings, Agent policy section: the Conflicts table listing Member, Harness, Surface, and Route for every selection that falls outside the current policy.
Use it as a visibility and follow-up tool: check it periodically, and reach out directly to anyone flagged if you want them to switch.
What is gated
The one thing that is gated is editing the policy itself. By default, changing the allowed routes or harnesses requires the organization to be on a paid plan (or hold an active unlimited-cloud entitlement). Viewing the current policy and the conflicts list is never gated by plan, on any tier.
Why it's built this way
A flag-only policy gives admins a way to state intent and see drift without risking a misconfigured allow-list locking the whole team out of their agents. If you're used to allow/deny lists that hard-block on the first mismatch, don't expect that here yet; treat this as reporting, not a firewall.
Related
- Source tiers for what the routes and harnesses in the policy actually mean.
- Guardrails for the controls that do have a more direct effect on what an agent can reach.