Source tiers
The three auth routes a policy can allow, and which agents they apply to.
The agent policy's Allowed routes checklist controls how members' coding agents are allowed to authenticate their model calls. There are three routes.
Allowed routes and Allowed harnesses checklists
Organization settings, Agent policy section: two checklists side by side, one per auth route (Native, API key, Gateway) and one per coding agent (Claude Code, Codex, OpenCode, Grok).
The three routes
| Route | What it means |
|---|---|
| Native | The agent uses its own CLI login (for example, signing in to Claude Code or Codex directly). Proliferate never sees or holds the credential. |
| API key | A raw provider API key, pasted in and bound to an environment variable the agent reads directly. |
| Gateway | Proliferate's own managed model gateway. The sandbox only ever holds a scoped virtual key; the underlying provider key never leaves Proliferate's servers, and usage draws from shared credits or budget. |
Checking every route (the default) means "no restriction." Unchecking one, for example leaving only Gateway checked, states that the team should route model calls through Proliferate's gateway rather than native logins or personal API keys.
Which agents it applies to
The Allowed harnesses checklist lists the coding agents the policy can restrict: Claude Code, Codex, OpenCode, and Grok. Leaving all of them checked means every supported agent is allowed; unchecking one flags anyone still using it.
Not every agent supports every route. Cursor, for instance, only ever uses its own native login and isn't part of the gateway routes at all, so it doesn't appear in this checklist.
Applies to cloud and local
The policy isn't scoped to cloud workspaces only. A member's setup is checked on both surfaces, cloud sandbox and local machine, and the Conflicts table (see Enforcement) shows which surface a flagged selection came from.