Allowed harnesses
Control which harnesses are available to agents.
Organization admins can restrict which coding agents and which authentication routes members are allowed to use. This is the agent policy, part of Settings → Org → Organization settings.
Screenshot: Settings > Org > Organization settings, Agent policy section
The Agent policy section of Organization settings, showing two checklists (Allowed routes, Allowed harnesses), a Save policy action, and a Conflicts table below.
Allowed routes
Which authentication routes members may use for any agent:
- Native (harness sign-in). Signing in to the agent's own account directly.
- API key. Supplying a provider API key.
- Gateway. Routing through Proliferate's managed LLM gateway.
Allowed harnesses
Which agents members may use at all: Claude Code, Codex, OpenCode, and Grok. Cursor isn't part of this list: it has no auth routes of its own, so there's nothing for this policy to restrict.
Leaving every box checked in a list means no restriction (Proliferate stores that as "no policy" rather than an explicit allow-list). Unchecking any box narrows that list to exactly what's checked.
Conflicts are flagged, not blocked
Below the checklists, a Conflicts table lists any member whose current harness or route selection falls outside the policy you just set, with their harness, surface, and route. This is informational: saving a stricter policy does not retroactively change anyone's existing selection or stop an in-flight session. Use the table to follow up with the members listed there.
Screenshot: Agent policy Conflicts table
The Conflicts table under Agent policy, listing member, harness, surface, and route for selections outside the current policy.
Who can edit this
Reading the policy is unrestricted, but editing it requires both an admin role and, on hosted Proliferate, an organization on a paid plan. If your organization is on the free plan, the checklists render read-only until you upgrade.
This is the one place an agent policy exists in the product today, and it is advisory: it flags conflicts rather than blocking sessions. There is a separate "Model policy" entry planned under Org → Policies for org-wide model availability and default routing; it is not built yet.