Agent authentication policy
Control which managed authentication routes members may newly configure for agent harnesses, and follow up on pre-existing conflicts.
This policy controls which managed authentication routes members may newly configure. Existing configurations that conflict stay usable and are listed for follow-up.
It gates writes to a member's authentication selections — the records wiring a harness to an API key or the gateway. It is not a harness ban and not retroactive. A member can still run a harness natively without creating such a record, and an older selection keeps working until they change it.
| Who | Owners and admins only; members cannot view or edit the policy or Conflicts table |
| Applies to | Managed route 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. Everything checked restricts nothing. Unchecking an item blocks members from newly saving a selection that uses it and flags existing ones.
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 — Claude Code, Codex, OpenCode, Gemini CLI, and Grok CLI. 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 a member with an existing selection on that harness has no compliant change to save: any enabled source fails the harness check, clearing every source counts as Native, and the route check then rejects that too. There is no delete path, so the selection stays stuck in Conflicts.
Agent selections are user-global: one selection covers every organization the member belongs to plus their personal context. A save is checked against all of them, so the strictest policy wins — and the rejection a member sees may come from a different organization than the one they are looking at.
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 every member selection whose enabled source falls outside the policy, by Member, Harness, Surface, and Source. All of them predate the policy change; new violating saves are blocked before they get here. A member clears a row by moving the selection to an allowed route or disabling it.
What admins cannot do#
Admins cannot see or manage the keys members save. Those stay in each member's own encrypted vault, shown only as a redacted hint. See Authentication for how members create, wire, and revoke them.
Per-model allowlists#
Coming soon. There is no per-model control today.
Edit gate#
Editing needs a paid plan or an active unlimited-cloud entitlement. Owners and admins can view the policy and Conflicts table without one; members cannot read either. An existing policy keeps enforcing regardless of the edit gate.