RENT THE INTELLIGENCE. OWN EVERYTHING IT TOUCHES.

By the time a prompt reaches the model, the decision has already been made for you. If your only control is a dashboard that reports what happened, you are reading a post-mortem, not enforcing a policy. The rule has to run before the request leaves your network, or it is not a rule.

Cowork's third-party inference setting expects an HTTP endpoint at /v1/messages that forwards the anthropic-beta and anthropic-version headers. systemprompt.io is that endpoint, deployed in your VPC. Every request runs through scope, secrets, policy, and quota checks before a token leaves your network.

Scope resolves the JWT to a principal and checks RBAC entitlement. Secrets scans the prompt for credential patterns and rejects or redacts. Policy applies blocklists, prompt classifiers, and per-tenant rules. Quota enforces per-user, per-tool, and per-budget limits. Each outcome (allow or deny) is recorded with the request's identifier so denials are evidence, not silent failures.

When an auditor asks which prompt triggered a tool call, who authorised it, and what the model sent back, a usage dashboard shrugs. It counts requests; it cannot name the person behind one. That gap is the difference between telemetry and evidence.

Cowork emits OTLP telemetry to whatever endpoint the otlpEndpoint managed preference points at. Useful for usage dashboards, insufficient when an auditor asks which prompt caused a tool call, who authorised it, and what the model returned. systemprompt.io captures that detail directly: prompt, completion, tool call, MCP invocation, and cost, written to your PostgreSQL as structured rows under one request identifier.

Forward the same stream as JSON to Splunk, ELK, Datadog, or Sumo Logic and the SIEM ingests it without a custom parser. Every record carries the JWT-verified user, session, and agent. Anonymous AI activity is not a state the system can be in.

Tie Cowork to a single inference provider and you inherit that provider's region, its pricing, and its next outage. Changing your mind later reads like a replatforming project instead of a config change.

Anthropic documents first-class managed preferences for several inference targets: Vertex (inferenceVertexProjectId, ...Region, ...CredentialsFile, OAuth client), Bedrock (inferenceBedrockRegion, ...BearerToken, ...Profile), Azure Foundry (inferenceFoundryResource, ...ApiKey), or anything generic via inferenceGatewayBaseUrl. systemprompt.io sits in front of all of them as one routing surface.

Pick the upstream per call, per department, per cost ceiling, or per region. Self-hosted Llama or Qwen behind a private ingress, Bedrock for production, Groq for the fast lane. The switch is configuration, not replatforming. When inference runs through your own cloud provider, prompts route to that provider rather than through Anthropic's API. With the gateway in front, the cloud provider sees a policy-checked request stamped with your attribution headers, not raw client traffic.

A credential that lives on the laptop is a credential that walks out with the laptop. One shared token pushed to every device means a single lost machine exposes organisation-wide spend and every user's audit identity.

Cowork's inferenceCredentialHelper managed preference expects an absolute path to an executable whose stdout is the inference credential, refreshed every inferenceCredentialHelperTtlSec seconds, with an auth scheme set by inferenceGatewayAuthScheme. A deployment that skips this and pushes one shared bearer to every laptop instead leaves a single lost device exposing organisation-wide spend and audit identity.

systemprompt.io provides the helper. It trades the workstation's SSO identity for a short-lived, user-scoped JWT against the gateway's auth endpoint, returning it to Cowork on stdout. The user never sees a key. Upstream credentials stay on the gateway. Revocation is a database update; the next helper invocation fails closed within the TTL window. Use inferenceGatewayHeaders to attach user, session, and trace identifiers to every outbound call so attribution propagates without sharing keys.

You can hand every laptop a list of approved tools, but a list on disk has no author, no per-team scope, and no way to pull a tool back once it is out. The configuration ships with Cowork; the control over it does not.

Cowork on third-party inference loads MCP servers from the managedMcpServers managed preference. Each entry has a name, url, transport (http or sse), either headers or oauth: true (PKCE), and a per-tool toolPolicy of allow, ask, or blocked. isLocalDevMcpEnabled = false blocks user-added servers; isDesktopExtensionSignatureRequired = true enforces signed extensions. The configuration surface ships with Cowork; the registry, signing authority, and revocation path do not.

systemprompt.io is that registry. Each MCP server is registered, scoped by RBAC role or department, signed with your keys, and distributed via MDM as one allowlist URL. Tool policy resolves per-principal, so the same Stripe tool can be allow for the payments team and blocked for everyone else. Built-ins can be culled from disabledBuiltinTools; egress can be pinned via coworkEgressAllowedHosts.

Org plugins arrive as folders dropped into a directory on each machine. Files on disk carry no provenance, no version history, and no way to withdraw one once a laptop already has it.

Cowork loads org plugins from a local directory: /Library/Application Support/Claude/org-plugins/ on macOS, C:\\ProgramData\\Claude\\org-plugins\\ on Windows. Each plugin is a folder with plugin.json, version.json, and any of agents/, commands/, skills/, or an .mcp.json. The mechanism ends at "files on disk"; provenance, revocation, version history, and per-department scoping are left to the enterprise.

systemprompt.io is the catalogue behind that mount. Plugins are authored or imported into the dashboard, signed, versioned, scoped by RBAC role. A per-device sync writes only the entitled set into the org-plugins directory. A withdrawal removes the plugin from every install before the next session loads it.

The same client, three deployment substrates. Three different answers to "where does the prompt go, who holds the audit, and how do you revoke a user."

Left to each user, a Cowork install is a dozen settings that can each land wrong: developer mode left on, an unapproved server added, a personal key pasted in. Every ungoverned laptop is a hole in the audit trail you will answer for later.

Two managed-config surfaces: macOS .mobileconfig under com.anthropic.claudefordesktop, Windows .reg under HKCU\\SOFTWARE\\Policies\\Claude. Anthropic exposes roughly forty keys spanning inference target (inferenceProvider, inferenceGatewayBaseUrl, the per-cloud Vertex / Bedrock / Foundry families), credential helper (inferenceCredentialHelper, inferenceCredentialHelperTtlSec), MCP (managedMcpServers, isLocalDevMcpEnabled, isDesktopExtensionSignatureRequired), telemetry (otlpEndpoint), egress (coworkEgressAllowedHosts), workspace (allowedWorkspaceFolders), token caps (inferenceMaxTokensPerWindow), update cadence (autoUpdaterEnforcementHours), and built-in gating (disabledBuiltinTools).

systemprompt.io ships profile templates for both platforms with the gateway URL, helper path, and allowlist preset. A user opens Cowork on a managed device and lands in a governed session. No Developer-mode toggle, no API key, no MCP setup question.