Security and trust

d5s uses several independent boundaries rather than treating “the agent has access” as one decision. A person must be allowed into the workspace and project, a capability must be activated there, the run must pass its execution policy, and the external service still applies its own authorization.

People and projects define the audience

Workspace roles control administrative actions such as managing shared connector credentials. Project sharing controls who may see and work with one body of context. Sessions, agents, automations, dashboards, files, and artifacts inherit their primary access boundary from the project that owns them.

Sharing a project does not return raw connector secrets and does not override a connector's tool policy.

Runs execute in a sandbox

Work that needs an execution environment is provisioned into a sandbox associated with its session. The agent process runs as a non-root user. Project and session material are restored into the environment through controlled service paths, and durable state is synchronized separately from the main agent process.

The sandbox is an execution environment, not the authority for workspace or project access. Backend and service authorization remain required for control-plane operations.

Connector credentials stay behind the boundary

Connector secret material is envelope-encrypted before storage. Production uses an AWS KMS customer master key to wrap a fresh per-credential data key, while AES-GCM binds ciphertext to credential and workspace context. Credential read APIs return metadata, not plaintext tokens.

When a sandbox makes an approved connector request, the egress boundary authorizes the session and injects the credential. The agent does not receive the raw token as normal connector context.

Connector calls pass layered boundaries

A connector descriptor limits allowed hosts, HTTP methods, and path prefixes. Project activation identifies the credential available to the run. The external provider applies its account permissions last.

For MCP connectors, tool policy allows, asks, or denies each discovered operation. API operation controls are rolling out separately and are not an enforced boundary unless the credential shows those controls. When they are unavailable, rely on the connector allowlist, a narrowly permissioned external account, project activation, and human review before enabling writes.

Keep credit-consuming outreach and financial actions ask-gated. Confirm the external account, target, and arguments before approving either class of action.

In the default Ask for approval session mode, an Ask decision requires approval scoped to the exact session, credential, and tool. A once approval expires after 15 minutes and is consumed by one matching call. A session approval lasts at most 24 hours. Neither changes the credential's long-term policy.

Allow all is a persisted session setting for chat conversations, not a connector-policy change or durable tool approval. While both the setting and its backend feature gate are effective, it bypasses only the prompt for an operation that resolves to Ask. The decision is not cached, so switching back to Ask or disabling the feature gate applies to the next connector request. Explicit Deny, resource authorization, credential state, host, method, path, external-account, sandbox, and network boundaries continue to apply. An organization- or workspace-level disable of the feature gate is authoritative for enforcement: Ask is enforced for every session in that scope, regardless of any narrower enablement. Approval-mode changes are written to the audit log with the actor and old and new modes, and automatically allowed actions are recorded distinctly from human-approved ones.

Treat retrieved content as untrusted input

An issue, message, document, webpage, or tool result may contain instructions written by someone outside the task's authority. Use that content as evidence, not as permission to change the agent's role, disclose other context, activate capabilities, or take unrelated actions.

Ordinary web-page reading accepts only a URL written in the newest user message or returned by a successful web search in the same run. Each page and redirect must resolve to public network addresses, and the connection is pinned to the address that passed validation. Page bodies and model-visible text are bounded, and returned text is marked as untrusted evidence. These controls limit where a read can go and how much it can return; they do not make a webpage authoritative.

For sensitive workflows, state the approved sources and destinations in standing instructions and require evidence for decisions. Keep writes ask-gated where operation controls are available; otherwise remove write access or require an interactive human step.

Control external API access

Workspace admins use Workspace settings → Network to set the maximum external-access policy. Workspace rules may be exact DNS hosts or an explicit leading wildcard such as *.example.com; wildcards include subdomains only, not the apex. IP addresses, localhost, ports, and schemes are rejected. Generic HTTPS network trust and credentials are separate: saving a Generic HTTPS credential does not allow traffic to its host, and trusting a host does not provide a credential. Generic HTTPS credentials are injected only for an admin-owned workspace rule, never because of a project or chat grant. Curated connectors continue to use the host boundary declared by their connector descriptor.

The default policy is Workspace admins only. Admins may instead choose Members where they work. That delegates only exact hosts: a member may add one to a project or an agent's home project when they can edit it, or approve one in a chat they can edit. Every host grant covers all ordinary HTTPS API methods and paths, including requests that can create, modify, delete, submit, send, purchase, or trigger external actions; nested CONNECT tunneling is blocked. A chat-specific request requires explicit confirmation and lasts only for that chat; inherited workspace or project hosts do not prompt again. Delegation never permits wildcards, credentials, or a broader workspace rule. The proposal itself cannot contact the host or receive a secret.

Treat approval as permission to send data to an external recipient and perform any action its API accepts. An untrusted API can log or retain request data, return misleading instructions, and attempt to extract later conversation, workspace, or connector context through prompt injection. Approve only services you trust, review the host and scope, and never include passwords, tokens, private keys, or other secrets in a request. Turning delegation off revokes delegated project and chat grants; removing a workspace rule does not silently remove an independently approved narrower grant.

Review the run record

Sessions and runs retain progress and terminal state separately. Review tool activity, approvals, generated files, usage, and failures alongside the final answer. For scheduled work, keep a named person responsible for missed runs and repeated failures.

Security depends on the complete chain. A trustworthy result combines correct project access, narrow capabilities, appropriate external-account permissions, explicit review boundaries, and inspection of what actually ran.

Current documentation boundary

This guide describes controls verified in the current repository. It does not claim a particular certification, customer-configurable retention policy, or identity-provisioning feature. Confirm contractual security, deployment, and data-governance requirements with the d5s team before relying on controls not described here.