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

For the region choice and its limits, see Choose where your organization's data is stored. For an overview, see Security.

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.

app.d5s.tech opens the EU region's 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. Select Continue in browser to sign in with your system browser and return to the EU app.

The selected region governs where d5s stores organization data. Authentication, payment processing, model providers, and other named subprocessors 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.

An organization Owner or Admin can connect ChatGPT, Grok, or Claude for use across the organization's workspaces. Members and agents can use the selected service without seeing the connected credential or account metadata. Only organization Owners and Admins can manage or disconnect it. Use an account your organization authorizes for shared use and review the connected service's terms.

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. An active or retained coding environment can block a chat move to another project. The API returns 409 and leaves the chat in its current project.

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 becomes part of that agent's activity history. 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.

Connecting Teams 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. Authorized d5s agent viewers can read activity from its currently bound Teams channels while the backing installations remain active, without a linked Teams identity or a separate Teams membership check. This read access does not grant provider actions or personal credentials. Activate only channels whose activity may be inspected by the agent’s d5s viewers. See Teams agent setup.

Coding work and received files

Work that needs a coding environment remains subject to the same workspace and project permissions. Slack files are available to the agent only when it accesses them for the task, subject to provider and product limits. A file name is not proof of its origin.

Connected account access

Connection settings show account information without displaying the credential. An approved connector action uses the selected account under its current permissions.

Review connector actions

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.

Connector actions can be allowed, require approval, or be denied. A connected account does not authorize every action it supports. Use an external account with only the permissions needed for the task 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 the manager delivers a message, the agent cannot read or act on it. Delivering one message does not trust future mail; trusting a sender adds only that exact address to the visible rules, and rejecting the message starts no agent work.

A managed d5s inbox also holds mail when its sender-domain authentication (DMARC) cannot be verified. A channel manager may release one message, persist an exception for the claimed From address, or allow all unverified senders for that mailbox. The mailbox's Review unverified email before the agent sees it control stays on unless a manager explicitly turns it off and confirms the risk. Persistent exceptions require a danger confirmation because the From address could be forged. These exceptions do not bypass spam, virus, malformed-message, blocked-sender, or other content checks. An agent's suggestion to add one or more exact email addresses changes nothing until someone decides the durable request. A blocked outgoing send may suggest To, CC, and BCC addresses together; each is decided separately or pending addresses can be allowed together. In bound Slack and Teams channels, any verified current member can allow or deny the request in that channel, including someone without a d5s account. In d5s, an authenticated channel manager can decide it; Telegram and email requests link to that d5s review. The first valid decision wins, and adding an incoming address does not bypass DMARC review.

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 Ask for approval mode, a one-time approval expires after 15 minutes and covers one action. A session approval lasts at most 24 hours. Neither changes the connected account's long-term policy.

Allow all lets actions that would otherwise ask for approval continue in that chat session. Switching back to Ask for approval applies to later actions. Explicit denials, account permissions, and organization or workspace requirements still apply. IMAP / SMTP sends still need approval of the exact email. Gmail and Outlook sends and Google Calendar and Outlook bookings always wait for an approval card. Automations, dashboards, and sub-agents cannot send or book from these accounts, and MCP tools that send email or book meetings are off. Approval-mode changes appear in the audit log. Workspace-secret Custom API requests always require Approve once, including reads and connection checks.

When a named agent asks for approval in a connected Slack channel, any member of that channel can decide the card, including someone without a d5s account. Connect channels with that decision authority in mind. The card works only in its original channel, can be used once, and expires after 15 minutes. Allow all skips Ask cards for that agent, subject to broader organization or workspace policy. Email sends and meeting bookings still wait for a card. When another agent's mention started the run, the card waits in d5s, not in the channel.

Linked Telegram and Discord direct-message approvals can be decided only by the linked account. Discord server approvals belong to the channel where the request appeared. Expired, copied, or reused approval cards cannot authorize an action.

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

Messages, documents, webpages, and tool results can contain instructions from someone outside the task. Treat them as evidence, not permission to change the agent's role, expand access, or take an unrelated action. The same applies to Slack and email attachments.

For sensitive workflows, name approved sources, recipients, and actions in standing instructions. Review proposed external actions and keep writes approval gated, or remove write access when an interactive human step is required.

Workspace computer Internet access

If agents show Computer, workspace owners and admins set one Internet policy under Settings → Workspaces → workspace name → Network. It covers website access from browsers, terminal commands and apps on that computer. Agents show the inherited policy in Network and open the desktop from Computer. They have no separate Browser policy or project override.

• All public websites permits public HTTP and HTTPS destinations. This is the default for newly created workspaces.
• Specific destinations permits only the exact hostnames you save, including hosts needed for redirects and page resources.
• Disabled blocks this public web traffic.

If Internet access shows Choose Internet access, select and save a policy before the computer can access the Internet. Changes revoke existing connections without restarting the computer. A reconnect failure is shown after saving; retry to reconnect. Private networks and cloud metadata remain blocked. Network access does not grant connector credentials, channel permissions or access to another project's files.

Connected API actions use their connector permissions separately. Disabling computer Internet access does not disable those actions. To stop them, remove the connection or deny the relevant connector actions.

Legacy sandbox settings opens the old workspace controls for retained sandboxes. These controls do not override the shared computer policy. The browser guidance below describes that legacy path. Connector action permissions apply to both paths. Existing saved sign-ins and sandbox policies are not changed automatically.

Review browser access

If you see Open privately, workspace admins can set up saved sign-ins privately. Only the admin who starts private setup can view or control that session. Agents cannot use the profile during private setup. This setup is unavailable while the workspace requires individual website approval. Stop and close stops the browser and keeps saved sign-ins; it adds no agent access.

An agent with approved browser access can start its saved browser under either conversation approval setting. The browser panel can stay closed. Browser startup does not expand website access or take over a private, deliberately paused, deliberately stopped, or busy browser. Website permissions still apply. See Browser start and stop.

Browser access defaults to on with public HTTPS websites for agents without a saved policy, unless the workspace requires website approval. Existing Off choices and website restrictions remain in effect. An agent without an assigned saved browser gets a separate one on first use. Existing saved-browser assignments are reused, including deliberately shared accounts. A workspace admin can change Allow browser and Website access in Browser settings, or deliberately share signed-in accounts through Advanced → Saved browser. Enable all websites allows navigation to public HTTPS sites. *Enable only .example.com replaces the agent's existing website list and limits navigation to that site and its subdomains. The browser can use accounts already signed in to its selected profile. Website text can mislead an agent, so review the requested task and the saved browser’s accounts before expanding access or sharing it.

The website scope controls navigation to public sites. Public page resources such as images, scripts, and other requests may load from other domains. Private network addresses remain blocked. With Browser access, an agent can also open one selected HTTP port in its current conversation's coding sandbox; that app stays private to the browser session and is separate from website approval. Workspace admins can require individual website approval under Settings → Workspaces → workspace name → Network → Websites; turning it on asks them to confirm. They can turn an agent's browser access off later. The workspace Browser tab shows the current setting in one line, with a Change in Network link for admins.

Control external API access

Workspace admins use Settings → Workspaces → workspace name → Network to choose which external API hosts can be reached. Rules may name an exact DNS host or an explicit leading wildcard such as *.example.com; wildcards cover subdomains, not the apex. IP addresses, localhost, ports, and schemes are rejected. Allowing a host does not provide a credential, and saving a Generic HTTPS credential does not allow traffic to that host. Curated connectors retain their own supported access limits.

Under Network → Advanced → Who can approve new hosts, the default is Workspace admins only. Admins may instead choose Members where they work. Members may add exact hosts to a project or agent they can edit. In a chat they can edit, a person may approve only the requested hostname or choose All websites for that chat. The chat card selects only the requested hostname by default; choosing all websites changes the button to Allow all websites and shows a warning before you grant that broader scope. Every grant covers ordinary HTTPS API methods and paths, including requests that can create, modify, delete, submit, send, purchase, or trigger external actions. Chat grants end with the chat, are removed when a persistent agent’s conversation is cleared, and can be revoked; inherited workspace or project hosts do not prompt again. Delegation does not grant 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. A supported MCP PDF download can import a returned file from its configured provider file host without a separate website-access approval. Other temporary links may require you to approve This website if you recognize the host; the agent may request a fresh link after approval because the earlier one can expire. 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 connector passwords, authorization headers, private keys, or other workspace secrets in a request. A chat-wide grant reaches public HTTPS DNS hosts only; private and internal destinations stay blocked. Turning delegation off revokes delegated project and chat grants; removing a workspace rule does not silently remove an independently approved chat grant.

Choose no-training routing at the user or organization scope

For personal work, no-training routing is a selectable preference. Every authenticated user can open Settings → Preferences → 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, including research and tools, uses the initiating user's selection. Unattended work uses the automation, dashboard, or agent creator's selection. A named agent's dashboard contribution also respects the agent owner'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 a personal or organization no-training selection is effective, work runs only on models that do not train on your data. If no eligible model is available, the work fails. Contact d5s if protected work remains unavailable.

Muse Spark 1.2 Contributor and Muse Spark 1.3 Contributor are no longer available. Their removal does not change your no-training preferences.

No-training routing controls which models run your work. Confirm retention, subprocessors, and contractual data-use terms separately.

Understand zero data retention for Team and Enterprise

Team and Enterprise require zero data retention for the primary models provided by d5s. This applies to every model d5s runs for you. If an eligible model is unavailable, the work stops. No setting is needed to enable this requirement.

Connected AI subscriptions are outside this requirement and follow the connected service's terms. Auxiliary services and tools have their own processing terms. The no-training preferences described above are separate controls.

Zero data retention concerns prompts and outputs at the model provider. It does not delete conversations, files or other content stored in your d5s workspace. See the account-closure guidance below and the Privacy Notice for storage, deletion and retention exceptions.

If a model is unavailable

Organization Owners and Admins choose, for every workspace in the organization, 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 Organization 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

Review tool activity, approvals, generated files, usage, failures, and the final outcome together. 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

d5s no longer collects request-access records. See the Privacy Notice for how earlier records are kept and deleted.

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.

After deletion from active systems, backup and prior-version copies may remain for up to seven days. The approved Privacy Notice in the legal center is authoritative for retention exceptions and rights.

Account closure has a bounded lifecycle

You can close your account from Settings → Profile under Account with Close account…. 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 determine where new customer organizations can be created. An organization's selected region governs storage of its organization data in d5s. Identity, payment processing, transactional email, model providers, limited error reporting, and other named subprocessors may process data elsewhere. Customer-selected connectors may send data to their external providers.

Confirm the applicable providers, subprocessors, transfer terms, and data location commitments 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. The acknowledgement for an online consumer withdrawal remains 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.

Google data protection

When you connect Google, d5s uses the information you authorize to complete the features and workflows you request. If a task uses AI, relevant Google content may be sent to the AI providers used by your workspace. Read the connection notice before choosing Acknowledge and connect and review the Privacy Notice.

Disconnecting removes the saved credentials but does not erase information already retrieved into conversations, files, or project memory. Removing a conversation does not remove project memory derived from it. You can revoke the provider grant in your Google Account settings and request erasure of stored information through privacy@d5s.tech. Connecting Google does not change workspace membership or authorize additional actions.

Pentest VM scope

If Pentest VM is available in your chat, use it only for the targets and actions you are authorized to test. Optional workspace Targets and notes help describe that scope. They do not enforce a network allowlist.

Commands run in the conversation's VM. Its files are temporary. Export reports before stopping the VM or letting it expire. A stop request is complete only when cleanup is confirmed.

Secrets and variables

If Secrets & variables is available, organization and workspace administrators can store credentials and readable configuration variables.

Enter credential values in the secure dialog. There is no reveal-value action. Sharing a secret with a workspace exposes its name and status. A secret can last Until revoked or until a date you choose. Website sign-ins can also be added from an agent's chat request; see website sign-ins from chat.

If an agent or project shows Link workspace secret, an administrator can select a shared secret and give it an environment name. Scripts in that agent or project's sandbox can then read the secret through that environment variable. This includes commands on its workspace computer, when available. Linking a secret to one project does not link it to another project on the same computer.

Each new command receives the current value. Rotation and link removal affect subsequent commands. A running command can retain a value it already received. An expired, revoked, or unavailable linked secret prevents a new command from starting until an administrator fixes or removes the link.

Secret values are omitted from tool arguments and masked when they appear directly in command output. Scripts can still copy or encode values into files or other output. Give access only to credentials the task needs.

Variables are readable configuration. A project can explicitly link a workspace variable. Its current variables are also available to sandbox commands when secret linking is available. Keep credentials in Secrets.