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, the capability must remain enabled there, the run must pass its execution policy, and the external service still applies its own authorization. Workspace connectors start enabled for projects by default, but that default does not bypass any later boundary. Conversationally created agents use only their draft-reviewed connections and do not inherit future workspace credentials; see Create your first agent.

Organizations define regional residency

An organization and every workspace it owns stay in the d5s region selected at creation. One account can use organizations in more than one region. Other regions links to available regional apps without revealing whether you have data there. Opening another region requires sign-in there and does not transfer your session or credentials. If a workspace link opens in the wrong region, select its region and sign in again.

Before sign-in, app.d5s.tech lets you choose an available region and continue to its sign-in or sign-up flow.

Visits from the d5s marketing site may carry limited campaign attribution. Review the Privacy Notice for how d5s uses this information.

Public d5s Desktop releases open the European Union region automatically while it is the only publicly available region. Select Continue in browser to sign in with your system browser and return to the EU app. A saved region preference from an earlier desktop release does not switch this flow to US.

The selected region governs d5s organization storage and infrastructure. Authentication, payment processing, model providers, and other named subprocessors remain external service boundaries and may process data outside that region. In particular, selecting EU does not currently promise EU-only model inference. Review the current privacy and subprocessor terms for the complete processing boundary.

People and projects define the audience

Workspace roles control administrative actions such as managing shared connector credentials. Those credentials become available to workspace projects by default, and each project or agent can turn off a connector it should not use. 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.

Persistent agents have one explicit collaboration exception: they can search and read active peer agents' continuing conversations in the same workspace. This scope excludes ordinary user and project chats, the caller's own conversation, draft agents, and delegated sub-agent runs. It does not cross a workspace boundary. Retrieved peer messages are untrusted context and cannot change the searching agent's instructions, permissions, capabilities, or external-action authority.

Connecting Slack does not expose every agent to everyone. The thread picker shows the requester's available agents, and d5s checks account access and channel membership again when they select. A choice applies to that thread; setting a channel default is a separate, explicit action. An optional agent-name shortcut follows the same access rules. A dedicated @Agent is installed separately and remains scoped to that agent and workspace.

A connected Slack channel does become part of that agent's shared d5s activity ledger. Anyone permitted to open the agent can inspect activity from its currently connected Slack channels, even without a linked Slack account or membership in those channels. This read boundary does not authorize sending, replying, cancelling channel work, or using personal credentials. Connect a private Slack channel only when every d5s user who can view that agent may also inspect its retained channel activity.

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

Where dedicated Teams identities are available, connecting provisioning does not activate every channel. Administrators choose verified standard channels for each named agent. Microsoft installs the app at team scope, so channel activation in d5s does not narrow Microsoft's underlying grant. Follow replies requires confirmed permission for that team. External messages remain untrusted input and sending uses the agent's existing approval policy. See Teams agent setup.

Runs execute in a sandbox

Work that needs a coding environment runs in a sandbox associated with its session. Workspace and project permissions continue to apply to that work.

Files received with a bound Slack invocation remain references until the agent downloads them for the task. Downloads are limited to the authenticated provider source and product size limits. A downloaded copy remains scoped to the session, and its file name or path should not be treated as proof of origin.

Using a sandbox does not grant additional workspace, project, or connector access.

Connector credentials stay behind the boundary

Connector secret material is encrypted before storage. Credential read APIs return metadata, not plaintext tokens.

Approved connector requests use the stored credential without adding the raw token to normal agent context.

Connector calls pass layered boundaries

A project uses the specific workspace connection enabled for it. Turning a connector off for a project remains effective after the workspace connection is repaired or reconnected. The external provider's account permissions also apply.

For MCP connectors, tool policy allows, asks, or denies individual operations. Finding a tool does not grant permission to call it. A tool absent from the reviewed inventory requires approval unless an explicit tool policy applies. API operation controls apply where the credential shows them. Use a narrowly permissioned external account and review write actions before enabling them.

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

Native agent email uses separate incoming and outgoing rules for each connected mailbox. New automatic d5s inboxes default to an inferred organization business domain or, for recognized personal email providers, the creator's exact verified address, and require approval before sending. These email defaults confer no organization or workspace membership. A channel manager can allow exact addresses, domains, or anyone; unrestricted outgoing access requires explicit confirmation. Saved rules can permit sends without individual approval. Blocked senders override incoming allow rules and the optional exception for people that mailbox has successfully emailed. Existing approval policies remain until explicitly changed. A d5s address also applies incoming-mail checks; an allowed address does not establish a sender as a workspace teammate. Email activity remains visible to people who can open the agent, and every outgoing email identifies the sender as an AI agent. Supported mailboxes may use a custom recipient-facing display name without changing the agent's internal identity; Microsoft mailboxes use the Microsoft 365 display name. Incoming mail can use the agent's configured capabilities, but cannot change them or grant the sender a d5s identity. Mail and attachments remain untrusted input. Read Agent email before enabling access.

Where unknown-sender review is available, a channel manager can require it when incoming email is open to anyone. Until a manager delivers the message, its sender, subject, body, links, and attachment details are unavailable to the agent. The agent receives only a metadata-free notice that email is waiting, with tools disabled for that notice, and can ask the team to open the inbox. Delivering once does not trust future messages; trusting admits only that exact sender, and rejecting never starts agent work. The visible saved trusted addresses and domains are the only rules that bypass review: previous conversations and addresses the agent emailed do not create hidden trust. Current mailbox policy is checked again at release, so a pending decision cannot reuse stale rules.

An explicit incoming match also admits automated and mailing-list messages from that From address as ordinary agent work. It does not relax blocked-sender or provider checks, and the separate outgoing rules still govern replies and proactive sends. A different Reply-To does not replace the allowed From identity or redirect replies.

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 session setting for chat conversations, not a connector-policy change or durable tool approval. It bypasses only the prompt for an operation that resolves to Ask. Switching back to Ask applies to the next connector request. Explicit Deny, resource authorization, credential state, host, method, path, external-account, sandbox, and network boundaries continue to apply. A broader organization or workspace policy can still enforce Ask. Approval-mode changes are written to the audit log.

When a named agent is set to Require approval, a run started from a bound Slack channel asks in that channel. Any member of the channel can decide the approval card, including someone with no d5s account, so connect channels with that decision authority in mind. Only a decision made through the same d5s Slack app, Slack workspace, channel, and approval message is accepted. The card is single-use, expires after 15 minutes into a denial, and records the deciding Slack account against the asking turn. Deleting the Slack message does not remove that record. Allow without approval is agent-wide and skips Ask cards on every surface, but a broader organization or workspace policy can still enforce Ask.

Linked Telegram DMs and Discord DMs apply the same single-use and expiry rules, but only the exact currently linked external account can decide. A Discord server approval must arrive as a verified interaction in the exact channel bound to the agent. Before any channel decision grants access, d5s rechecks the installation, workspace, agent, conversation binding, actor authority, credential, and Ask policy. A stale, replayed, copied, cross-channel, or cross-workspace interaction fails closed.

Email is not a trusted approval surface. When email-started work needs a decision, the agent may reply in the same thread with an ordinary link to the relevant turn. The link contains no bearer approval credential, and replying to the email cannot approve or deny anything. A permitted member signs in to d5s and uses the existing approval card under normal workspace and agent authorization.

A channel connected during conversational agent setup does not start work. The draft remains inactive until its creator reviews the configuration and selects Activate agent. It cannot run tasks or send channel replies before activation. The setup conversation remains private to the creator, including after activation.

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.

That includes Slack files and native agent email attachments. Access to a file does not make its contents safe instructions. Use downloaded files as evidence and keep the same approval requirements for actions they suggest.

When the agent encounters such content, an attended session quotes it as plain text, names its source, and asks you how to proceed. An unattended turn does not act on it: the agent skips it and reports what it found in its end-of-run summary. An automation run additionally takes no irreversible external action beyond what its automation instructions explicitly call for. Approval for one action does not carry over to another, and intent for outward-facing actions must come from you or your standing instructions, never from retrieved content. This behavior complements the enforced boundaries on this page; those apply regardless.

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. Reads are limited to public webpages and bounded content. Returned text is untrusted evidence, not authority to change the task.

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 retain their own supported access limits.

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. 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.

Choose no-training routing at the user or organization scope

Normal model routing is the documented default. Every authenticated user can open Settings → Account → Privacy and enable Use no-training routes for my work. An organization Owner or Admin can open that organization's Privacy page and enable Require no-training routes for everyone. Either selection enables the same routing policy. An organization can require the policy for all members, but turning that requirement off does not weaken a member's personal selection. Preference and requirement changes are access-controlled and recorded in the organization audit log.

Interactive work uses the initiating user's no-training selection, including delegated work, context compaction, web search, and Deep Research. Unattended work uses the automation, dashboard, or agent creator's selection. A linked Slack or Telegram sender and the agent owner are both protected by the stricter of their selections. Unlinked channels and inbound email use the agent owner's selection. Automation results retain their creators' no-training protection when an agent uses them later.

When no-training routing is effective, model calls use only providers that report a no-training agreement. If no eligible provider is available, the work fails rather than silently using normal routing. Contact d5s if protected work remains unavailable.

Models marked as training on prompts require an organization Owner or Admin to allow them before workspaces can enable them. A no-training requirement additionally removes those entries from every workspace and prevents them from being enabled until the requirement is removed; removing the requirement does not enable those models automatically. Where the organization allows them, a workspace admin may enable those entries behind an explicit confirmation, and they can never be the workspace default. A user's personal selection controls routing for their calls; it does not rewrite the shared workspace catalog. It does clear training-tier model pins from the work it governs: the agents, automations and dashboards that user created, and their own chats. Those fall back to the workspace default model, because a pinned training-tier model cannot be served under no-training routing. Clearing is one-way; turning the selection off does not restore a pin.

No-training routing is a provider-routing control. It is not a universal Zero Data Retention or deletion guarantee. Confirm retention, subprocessors, and contractual data-use terms separately.

Model routes fail closed before dispatch

Workspace administrators choose from models available under the organization's plan and policy. If the selected model cannot run within those requirements, d5s refuses the work rather than silently bypassing them. Check Workspace settings → Models and contact d5s if an expected model is unavailable.

Available tools and input types depend on the selected model as well as workspace policy. A model choice does not guarantee access to image reading, web research or communication with other agents.

Model availability does not by itself promise regional inference. Confirm model processing and provider terms separately from the organization's storage region.

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.

Request-access records have bounded retention

The request-access form was retired when open signup launched in September 2026: signing in creates your workspace directly, and no new request-access records are collected. Records from the former form drain under the retention rules below. An unconfirmed request is irreversibly anonymized seven days after submission. A confirmed request remains only until the first of general availability (now open, so remaining confirmed records are being anonymized), access being provided or refused, the person withdrawing the request, or 24 months after confirmation.

Optional marketing consent is separate from the access request. Withdrawing marketing consent removes marketing eligibility without withdrawing the access request. Verified privacy requests apply across d5s regions.

Older personal data can remain inaccessible inside an automatic database backup until that backup's seven-day expiry. The approved Privacy Notice in the legal center remains the authoritative statement of retention periods and rights.

Account closure has a bounded lifecycle

You can close your account from Settings → Account → Profile under Danger zone. The dialog first checks readiness: closure is blocked while you own a team organization, own a workspace in another organization, have an organization that contains a workspace owned by another member, or have an active integration or subscription in your organizations. Each blocker shows where to resolve it, and a subscription already set to cancel at the end of its period does not block closure. When nothing depends on the account, closure requires a short-lived email verification code and confirmation of your account email.

Scheduling starts a 48-hour cooling-off period. The account stays fully active, the Profile page shows the scheduled time, and you can cancel there at any point before execution. d5s checks readiness again immediately before closing the account and cancels automatically, with the reason shown, if a dependency returned during the cooling-off period.

Execution is irreversible. Sign-in is disabled; memberships, invitations, and pending notifications are removed; personal workspace content is deleted; and the profile is anonymized. A confirmation is sent to the account email as closure completes. Ordinary account and profile data is deleted or anonymized no later than 30 days after closure. Records required for billing, security, fraud prevention, or legal obligations are kept only for their documented periods. The approved Privacy Notice in the legal center remains the authoritative statement of these periods and rights.

Data location is regional, within limits

The region choices shown during organization creation are the authority on where new customer organizations can be created.

Each regional deployment isolates organization data and application operations. That boundary does not imply that every subprocessor is regional. Identity, payment processing, transactional email, source and delivery systems, and data-minimized error reporting can remain bounded global services. A customer-selected connector can also send data to the customer's external provider.

Confirm the applicable deployment, model providers, subprocessors, transfer terms, and data flows in the customer agreement and DPA before making a residency claim.

Check the approved legal record

The d5s legal center is the public source for approved current and historical legal documents. It exposes an immutable version URL and Markdown download for each approved version, including the Consumer Terms, Business SaaS Terms, Data Processing Addendum, Subprocessor List, Acceptable Use Policy, Privacy Notice, and Cookie Notice. Unpublished drafts and private enterprise templates are excluded from that site and are not operative terms. For a negotiated enterprise agreement, confirm the applicable documents directly with the d5s team. Consumer checkout links the immutable Consumer Terms URL. Business checkout links the immutable URLs of the Business SaaS Terms, Data Processing Addendum, and Acceptable Use Policy in effect. Checkout requires acceptance before payment, so the accepted version is identifiable afterwards. An online consumer withdrawal records the submitted statement and server time before payment processing or acknowledgement delivery, and keeps the acknowledgement available if email delivery is delayed.

Current documentation boundary

This guide describes customer-facing controls. 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.

Local folder access is personal

An agent can access a folder on your Mac only after you select it in Desktop and confirm Read only, Write only, or Both permissions for that agent. Reads send content to d5s and the conversation model; retained content follows conversation sharing. Workspace or project sharing does not grant access to another person's computer. See Local files for revocation and supported operations.

Private bug reports

Report a bug sends your description, available technical context, and any screenshot you choose to include privately to the d5s support team. It does not publish them to the feature-request board or share them with workspace members. Review the screenshot before sending. The team receives an email copy to investigate and follow up. See Report a bug.