Connect and manage a connector

Connecting creates a governed credential in the workspace and makes it available by default to every project in that workspace. Chats, agents, automations, and dashboards use projects under the hood, so they inherit the connector too. Remove the connector from an individual project—or from an agent through its managed home project—when that work should not use it.

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. When methods identify different data regions, choose the region where the external account is hosted.

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.

During reconnect, the provider may reuse an existing signed-in browser session and return to d5s without showing another login page. The successful return confirms the workspace credential only. Check the intended project or agent under Connectors before relying on it in a run.

To connect the same provider again, return to the directory and choose Add another. Use names that make the account or environment clear, such as Notion — Sales and Notion — Product. Each connection remains independently selectable, rotatable, auditable, and removable. OAuth providers can reject a second connection when it resolves to the same external identity; in that case, reconnect the existing credential instead.

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

Select a social publishing destination

For X, completing OAuth selects that X account automatically. Give the connection a name that makes the public account clear, especially when the workspace connects more than one account.

For LinkedIn Pages, connect with a LinkedIn member who administers the intended company Page. Open the installed LinkedIn connection, find Publishing destinations, and select the Pages agents may draft for. Page selection is a workspace-admin action and can be changed later. If no Page appears, confirm the member's current Page role in LinkedIn, then reconnect and try again.

Activating the credential makes its selected destinations available to that project. It does not authorize publication: every social draft still requires a separate exact-revision approval in its originating conversation.

For Custom MCP server, enter the full HTTPS endpoint and choose OAuth sign-in or a bearer token. OAuth works when the server advertises compatible authorization metadata and supports Client ID Metadata Documents or public dynamic client registration. A server that requires a separately registered OAuth application may need a supported catalog integration or a provider-issued bearer token. Reconnect uses the existing connection's saved URL; add another connection to use a different endpoint.

3. Review where it is available

New credentials attach to projects that use workspace connector inheritance, including the hidden projects behind standalone chats and agents made through advanced creation. Agents made through conversational creation use explicit access: they receive only the connections reviewed in their draft and do not inherit future workspace credentials. Their access can be changed later in agent settings. For a project, open its Context area and choose Connectors. For an agent, select the Manage agent settings icon in the breadcrumb, then choose Connectors; this updates the agent's home project.

Remove a connector there when that project, chat, or agent should not use it. That opt-out remains in place when the credential is repaired or reconnected. You can add it again later from the same view. The agent's Add connector control lists workspace connectors that were removed from that agent above the full provider catalog. Creating a new workspace credential still requires connector-management permission.

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

The first active connection for a provider becomes its project default. Later connections are not default unless you explicitly replace it. If the default is deactivated while another connection remains, select a new default before asking the agent to use that provider without naming an account.

Choose the intended account when asking an agent to use a connected service. Accounts from the same provider remain separate, and an unavailable account never causes a silent switch to another connection. Approvals and activity records stay associated with the selected connection.

If two connection methods conflict on the same project, d5s keeps the existing method rather than making authorization ambiguous. Remove it before adding the other method to that project.

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. An operation missing from the reviewed inventory requires approval unless it has an explicit tool policy, even when its name looks like a read. API operation controls are shown only for credentials that support them.

Refresh the credential's tool inventory when a provider adds or changes operations. A failed refresh retains the previous inventory instead of replacing it with an incomplete list.

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, connector permissions, or workspace access restrictions.

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. 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, whether it was removed from this project, tool policy or live approval, and the external account's own permissions.

For a social connector, ask the agent to prepare a short test draft for the named account or Page. Confirm that the preview shows the intended destination, copy, and image before approving. After publication, open the reported provider link. If delivery is uncertain, inspect the external account before creating or retrying any equivalent post.

Azure DevOps repository access

When Azure DevOps is available in your deployment, connect with the Microsoft work account that has access to your Azure DevOps Services organization. Your company administrator may need to approve the connection. On-premises Azure DevOps Server is not supported by this connection.

Give the agent your organization name or URL and the repository you want it to inspect. It can browse directories, read source files and search code within the connected account's permissions. For example: “In organization Contoso, read the API authentication code in repository Platform and explain how it validates requests. Include the file paths and branch you used.”

This connection is read-only. It does not push code, run pipelines or grant access to Azure infrastructure. It also does not narrow a broadly authorized account to the repository named in your prompt. Use an appropriately scoped external account and review which d5s projects share the connection.

Microsoft 365 SharePoint and OneDrive access

Connect Microsoft 365 with the Microsoft work or school account that has access to the SharePoint sites and OneDrive files you want the agent to read. On work accounts your company administrator may need to approve the connection: reading SharePoint sites requires a permission that many tenants reserve for admin consent. Until it is granted, the sign-in ends on Microsoft's approval page and the connection is not created.

Give the agent the site, library or document you want it to inspect. It can search sites and files, browse document libraries and lists, and read list items, site pages and file metadata within the connected account's permissions. It does not download file contents. For example: “In the HR site, list the documents in the Policies library that changed this month and who last modified them.”

This connection is read-only. It does not upload, edit or delete files, and it does not change list items or sharing. It also does not narrow a broadly authorized account to the site named in your prompt. Use an appropriately scoped external account and review which d5s projects share the connection. Mail and calendar stay on the separate Outlook connection.

Use connector results in analysis

Connector results can be used directly or opened in the coding environment for analysis.

Opening a saved result does not repeat the provider action. A provider action can succeed even when saving its output fails; check the reported outcome before attempting another action.

Remove access

Remove a credential from the project when only one project, chat, or agent should stop using it. Disconnect the workspace credential only when nothing in the workspace should use that connection. The confirmation warns that projects and agents using the connector will lose access immediately.

Disconnecting permanently removes the saved credential and its project attachments; it does not change data or permissions in the external service itself. Connecting the provider again creates or repairs workspace authentication, but does not silently restore access for projects or agents that use explicit connector grants. Activate the new connection from each intended project or agent.