Power belongs behind a boundary.

Working Machines separates agent reasoning from provider credentials and external execution. Agents receive structured capabilities and results, while the runtime owns authentication, connection selection, policy checks, provider calls, and execution records.

This reduces credential exposure, but it does not make every action harmless. The selected provider permissions and the data returned by an action still matter.

Compatible MCP clients use OAuth 2.1 authorization and protected-resource discovery. Direct HTTP API clients use Working Machines bearer runtime tokens. Administrator access is separate from runtime access.

Clients should validate the authorization server metadata, use PKCE where required, and request only the scopes needed for the session.

Provider credentials stay inside the runtime and are not returned by discovery or execution APIs. Provider-native scopes determine what an individual connection can do. Named connections make the acting account explicit when a workspace has several accounts for one provider.

Workspace policy can restrict providers, actions, connections, and execution contexts. A rejected action is not treated as successful work. Sensitive or destructive operations should require a current, explicit user confirmation even when the technical policy allows them.

• Inspect action schemas before execution
• Confirm destructive, financial, or externally visible work
• Use idempotency keys for retryable writes
• Verify structured results before reporting completion

Provider HTTP requests use a shared guarded egress layer that validates target URLs, redirects, and DNS-resolved addresses. Private-network access is explicit and deployment-gated. User-supplied download URLs remain public-only even when a deployment allows trusted private provider hosts.

Do not place secrets or exploit details in a public issue. Use the dedicated Responsible Disclosure form to report the affected surface, likely impact, and minimum safe reproduction steps privately.