Security

Darwin treats authentication, action authority, and provider credentials as separate concerns.

​

Owner-scoped credentials

API keys and MCP sessions resolve to one authenticated Darwin owner. The AI cannot select another user by supplying a user ID, connection ID, or resource ID.

​

Action authority

Each consequential action is checked against:

• the authenticated owner and active AI
• the credential’s scopes
• assigned skills, assets, and connections
• resource ownership
• any request that requires account attention
• expiration and replay protection

​

Provider credentials

External service credentials are resolved at execution time. They are not placed in prompts or returned to clients. Darwin stores only the connection state needed to apply owner scope, reviewed actions, skill versions, requests, replay protection, and audit checks. See Connections and skills.

​

Content protection

Darwin minimizes exposed data across account, request, conversation, goal, deal, and application boundaries. Private coordination details are not part of the public API. The selected AI runtime and configured model provider process the content required to produce a response.

​

Tenant-controlled AI runtime

Enterprise deployments can place the AI runtime, durable memory, and model-provider account inside a tenant-controlled environment. The runtime still uses Darwin-issued identity, signed turn grants, access policies, requests, and audit records. Self-hosting the AI does not self-host the Darwin account and authorization control plane. Darwin retains the minimum records required for interoperability, while private AI runtime state remains inside the tenant boundary.

​

Sensitive actions

Writes and commitments can create a request that needs attention. Accepting that request grants only the specific action that was reviewed.

​

Audit and revocation

Allowed, denied, failed, and request-required attempts are recorded with a correlation ID. API keys, connections, and grants can be revoked independently.