Connect and activate a connector

Connecting and activating are separate operations. A connection creates a governed credential in the workspace. Activation makes one credential available to one project—or to an agent through its managed home project.

1. Choose the external account

Before opening d5s, decide which account should authorize the integration. Prefer a dedicated service or team account when continuity matters, and grant it only the provider permissions required for the intended work.

d5s cannot use the connector to reach objects the external account itself cannot access. Conversely, broad provider access is not automatically narrowed to one folder or repository unless the provider authorization or connector offers that boundary.

2. Connect in the workspace

Open Connectors, find the provider, and choose an available connection method. Depending on the generated connector definition, the flow may use OAuth, an access token, a host supplied with the credential, or a remote MCP authorization flow.

Some providers present multiple methods under one name. Compare each method's generated access summary and choose based on the work the project must perform, not only on setup convenience.

Complete the provider flow and give the connection a recognizable display name when the form allows it. The credential should appear as active. A Needs reauthorization state means its external authorization must be repaired before new runs can rely on it.

Only workspace roles with connector-management permission can create or archive shared credentials.

3. Activate it on a project or agent

For a project, open its Context area and choose Connectors. Select the workspace credential to activate. For an agent, select the Manage agent settings icon in the breadcrumb, then choose Connectors; this updates the agent's home project.

Activation does not copy or reveal the underlying secret. It creates the project-level grant that lets runs in that project request the connector.

If two connection methods conflict on the same project, d5s prevents an activation that would make authorization ambiguous. Keep the one method the project should use.

4. Review tool policy

Open the credential's tools or permissions view when available. Each operation can resolve to:

• Allow — run without pausing;
• Ask — require a matching approval in the current session; or
• Deny — block the operation.

For MCP connectors, discovered tools are enforced individually. API operation controls are rolling out separately and may not appear for every connector. Unknown governed actions ask rather than silently expanding access.

Where operation controls are available, start with write-capable actions set to Ask. If an API connector does not expose them, use a read-only or narrowly permissioned external account and keep writes interactive. Approve the exact action only after checking its target, arguments, and expected side effect.

The chat composer controls how Ask actions behave for that session. Ask for approval pauses and shows an approval card. Allow all lets Ask actions continue without individual prompts until the session is switched back. It does not override Deny or any credential, host, method, path, sandbox, or network restriction.

5. Test from the intended project

Run a small read request from the project or agent that will use the connector. Verify the selected source and inspect the tool record. Then test any required write in Ask mode before enabling a schedule or heartbeat. If you later use Allow all, confirm that the session's standing autonomy is appropriate for every manual and autonomous turn that can reuse it.

If the connector is unavailable, check the boundaries in order: public availability, credential state, project activation, tool policy or live approval, and the external account's own permissions.

Remove access

Deactivate a credential when only one project should stop using it. Archive the workspace credential when no project should use that connection. Archiving also removes its project activations; it does not change data or permissions in the external service itself.