Agent authentication policy
Control which managed authentication routes members may newly configure for agent harnesses, and follow up on pre-existing conflicts.
The agent authentication policy controls which managed authentication routes members may newly configure for their agent harnesses. Existing conflicting configurations remain usable and are reported for follow-up.
This is prospective model-access governance, not an org-wide harness ban or a retroactive security boundary. It gates writes to a member's authentication selections — the records that wire a harness to an API key or the managed gateway. A member can still run a harness natively without ever creating such a record, and any selection that predates a policy change keeps working until the member updates it.
| Who | Owners and admins only; members cannot view or edit the policy or Conflicts table |
| Applies to | Cloud and Local selections |
| Requires | Paid plan or an active unlimited-cloud entitlement to edit; owners and admins can view without one |
| Affects | New authentication selections a member saves (see disclosure below) |
What the policy governs
Two independent allow-lists in Settings → Organization → Model policy. Leaving everything checked restricts nothing; unchecking an item blocks members from newly saving a selection that uses it and flags any existing one.
Allowed routes — the authentication routes a saved selection can use:
| Route | Meaning |
|---|---|
| Native | The agent's own CLI sign-in, using its own account and any subscription tied to it. The credential does not reach Proliferate. A selection with no enabled source counts as native. |
| API key | A provider key the member pastes and wires into the agent. The key stays in the member's own encrypted vault. |
| Gateway | Routing through Proliferate's managed gateway. |
Allowed harnesses — the coding agents the pane governs today: Claude Code (Anthropic), Codex (OpenAI), OpenCode (provider-flexible), Gemini CLI (Google), and Grok CLI (xAI). Cursor is absent by design: it only ever uses its own sign-in, so there is no managed route to restrict.
How it works
- Saves are gated, not runs. Saving a selection that falls outside the policy is rejected with a policy-violation error, and the member sees which route or harness the organization disallows. Nothing already running or already saved is touched.
- The harness check applies only to enabled sources. Disallowing a harness blocks newly wiring an API key or the gateway into it; it does not stop native use, which uses no managed source.
- The route and harness checks are independent, and a save must pass both. The stricter of the two decides the outcome, so a save can be rejected on the route even when the harness is allowed, or on the harness even when the route is allowed.
- Existing selections are never rewritten or disabled. They keep working and surface in the Conflicts table until the member updates them.
- Enforcement is independent of the paid-plan edit gate below. A policy set while entitled keeps blocking new violations and flagging existing ones even if the entitlement lapses.
If you disallow a harness, keep Native on the route allow-list — otherwise members with existing selections on that harness have no way to save a compliant change. Any enabled source fails the harness check, and clearing every source counts as Native, which the route check then rejects; there is no delete path, so the selection stays stuck in Conflicts.
Agent selections are user-global: one selection applies across every organization the member is in and their personal context. A new save is checked against every organization the member belongs to, so the strictest policy wins. The member may see a rejection triggered by a different organization than the one whose settings they are viewing.
Per-agent route nuances
- Claude Code, Codex, and Grok use one active source at a time. Enabling the gateway or a key switches the other off.
- OpenCode is additive: the gateway and several provider keys can apply at once, since it calls more than one provider.
- Cursor always uses its own sign-in and is Local only. It has no managed route to configure and is not part of the policy.
The Conflicts table
The table lists each member selection whose enabled source falls outside the current policy, by Member, Harness, Surface (cloud or local), and Source. These are selections that predate the policy change — new violating saves never get this far, since they are blocked. To clear a row, the member updates the selection to an allowed route, or disables it.
What admins cannot do
Admins cannot inspect or manage the key values members save. The policy governs which routes members may newly configure; the keys themselves stay in each member's own vault, encrypted, shown only as a redacted hint. For how members create, wire, and revoke keys, see Authentication.
Per-model allowlists
The pane notes that per-model allowlists are coming soon; there is no per-model control today.
Edit gate
Editing the policy requires the organization to be on a paid plan or to hold an active unlimited-cloud entitlement. Both the policy and the Conflicts table are owner- and admin-only endpoints; members cannot read either. Owners and admins can view them without a paid plan. An existing policy keeps blocking new violations and flagging existing ones regardless of the edit gate.