Integration Identity Isolation

Enterprise customers with sensitive teams — legal, finance, compliance, security — often need a hard guarantee that one team’s integration identities are invisible and inaccessible to the rest of the organization. This page walks through the two isolation patterns Kindo supports, how agents behave when running against an isolated integration, and the current limitations.

If you are looking for the underlying mechanics (org-level toggles, group-level overrides, multiple-group rules), start with Tool Action Access Controls and User Groups. This page composes those primitives into a guide for the isolation use case.

Who This Is For

You should read this page if you need to answer one or more of the following questions for a security or compliance review:

• “Can the Legal team’s Jira identity be used by anyone outside the Legal team?”
• “If an admin creates a workflow that uses a shared Salesforce connection, can a member of a different team unintentionally run it with the admin’s credentials?”
• “When an org-wide agent invokes a tool, whose credentials are used — the agent author’s or the user running the agent?”
• “How do I prove to an external reviewer that team A cannot see team B’s connected services?”

Threat Model

Identity isolation in Kindo addresses three concrete risks:

Risk	What it means	Where Kindo enforces it
Discovery	A user outside the trusted team sees that the integration is connected, or sees which tools it exposes.	Org-level default-deny policy + per-group integration enablement (Tool Action Access Controls).
Direct use	A user outside the trusted team invokes a tool from the integration directly (chat, agent, API).	Same as above — tools the user’s groups have not enabled are filtered out of the user’s tool list, and the runtime rejects calls to tools they have no entitlement for.
Indirect use via shared workflow	A user outside the trusted team runs a shared workflow or agent that was authored against the trusted team’s connection.	Connection sharing scope (user-group-scoped only) + runtime Cerbos USE_INTEGRATION_CONNECTION check during tool assembly (only tools backed by an authorized connection are registered for the conversation).

The patterns below are designed so that all three risks are closed simultaneously when configured correctly.

Isolation Approaches

Kindo supports two complementary isolation patterns. Most enterprise deployments combine both.

Approach 1: Group-Scoped Integration Access

Make the organization’s default policy deny-by-default, then explicitly grant the integration to the user group that should have access. Members of other groups do not see the integration in their tool list, cannot create a connection to it, and cannot invoke its tools.

Use this when the integration itself should be invisible to everyone outside the trusted team — for example, a legal-team Jira workspace whose existence should not be discoverable by engineering or sales.

1. Create the trusted user group — Open Settings > User Groups and create the group (e.g., Legal). Add only the users who should have access. See User Groups.

2. Set the org-level default to deny — Open Settings > Security > Integration & Tool Access and set Default Integration Config Access to Off. This prevents newly added integrations from being auto-accessible. Then, in the same table, confirm that the specific integration you want to isolate is explicitly set to Active at the org level — this is required because the org-level toggle is a ceiling and the group-level enablement in Step 3 only takes effect for integrations that are org-level enabled. Optionally set Default Tool Access to Off so individual tools within an integration also require explicit enablement. See Tool Action Access Controls — Configuring Organization Defaults.

3. Enable the integration for the trusted group only — Open Settings > User Groups, select the trusted group, open the Integration & Tool Access tab, and toggle the integration to On. Only members of this group can now see and use the integration; other groups have no entitlement and see nothing.

4. (Optional) Restrict to a subset of tools — Expand the integration in the group’s settings and enable only the specific tool actions the team needs. Leave write or destructive tools disabled if the team only needs read access.

What users in the trusted group see: The integration appears in their connection list and chat tool list. They can create their own connection (or use a shared connection — see below) and invoke any enabled tool.

What users outside the trusted group see: Nothing. The integration is filtered out of the integration picker, the chat tool list, and the agent builder. Tool calls referencing it would be denied at runtime, but the user has no surface to attempt one from.

Note

Audit overlapping group memberships. Permissions are additive across groups — if a user belongs to the trusted group and to any other group that also enables this integration, they will see and use it from either path (User Groups — Access Control Rules). For isolation to hold, enable the integration only in the trusted group, and review the memberships of users who appear in the trusted group to make sure they aren’t picking up access through a broader group.

Caution

Do not set the integration itself to Off in the org-level Integration & Tool Access table as a way to scope access. The org-level integration toggle is a ceiling — when an integration is Off at the organization level, no user group can re-enable it for its members (User Groups — Integration Access). Isolation must be configured through the default-deny policy plus per-group enablement, not through an org-level Off.

Approach 2: Individual Connections with Downstream Permissions

Allow every user to connect to the integration with their own credentials. The downstream service’s permission model (e.g., Jira project permissions, Salesforce profile-based access) governs what each user can actually do. Kindo treats each connection as independent — no user can use another user’s connection unless it is explicitly shared.

Use this when the integration is enabled organization-wide but each user’s view of it differs because of upstream permissions. For example, every employee has a Jira account, but the legal-team Jira project is restricted to legal at the Jira level. A non-legal user authenticating to Jira through Kindo simply cannot see the legal project — isolation is enforced by Jira, not by Kindo.

1. Keep the integration broadly available — Confirm the integration is accessible at the organization level (either explicitly Active in the Integration & Tool Access table, or covered by an allow-by-default org policy) so any user in any group can connect.

2. Require individual OAuth authentication — Each user connects with their own credentials via Settings > Integrations. Kindo stores the connection scoped to that user only.

3. Do not share connections across groups — Avoid the shared-connection flow described below for integrations where downstream permissions are doing the isolation work. Sharing a connection bypasses the downstream identity boundary.

4. Verify downstream isolation — Confirm that the external service’s permission model actually enforces the boundary you expect. Kindo’s audit log records each tool invocation, including connection metadata in the event’s Raw Data payload (see Audit Log), but the content the user sees is governed by the external service.

Trust assumption: This pattern delegates isolation to the external service. If the external service’s permission model is misconfigured, Kindo will faithfully reflect that misconfiguration. Approach 1 is stronger in this respect because Kindo enforces the boundary itself.

Combining Both Approaches

For the strongest isolation, combine the two:

• Set the org default to deny, keep the specific integration set to Active at the org level, and enable it only for the trusted group (Approach 1) — so non-trusted users never see it.
• Within the trusted group, require each user to connect with their own credentials (Approach 2) — so even within the trusted group, downstream permissions further scope what each member can do.

This is the recommended posture for highly sensitive teams (legal, finance, security).

Shared Integration Connections

Administrators can share an integration connection with one or more user groups. A shared connection appears to group members as a usable connection on chat, agents, and workflows — they do not need their own credentials to the external service.

Sharing scope is per user group. A connection can be shared with the Legal group without being visible or usable to any other group. The sharing relationship can be managed from the user group’s Integration & Tool Access tab or from the integration connection’s sharing options.

Sharing does not bypass group-level integration access. A user group must have the integration enabled at the group or organization level to use a shared connection. If the integration is disabled for the group, shared connections of that integration are also unavailable to the group’s members.

Connection sharing is the only way Kindo grants one user access to another user’s credentials. Without an explicit share, every user can only use connections they personally created.

Caution

A shared connection means group members are acting under the admin’s identity from the external service’s perspective. The external service’s audit trail will attribute actions to the admin’s account, not to the user running the agent. Use individual connections (Approach 2) where attribution at the external service matters.

How Agents Interact with Isolated Integrations

A frequent enterprise question is whether running a shared agent or workflow silently broadens a user’s effective credentials. Kindo’s runtime is designed so that the answer is no: an agent invoking a tool always uses a connection the running user is authorized to use, not the author.

Default Behavior (No Pinned Connection)

When an agent or workflow invokes a tool and the author has not pinned a specific connection:

• Kindo resolves the connection from the running user’s authorized set — their own connection plus any connections shared with their groups.
• If the running user has no authorized connection for the integration, the tool call fails. The agent does not fall back to the author’s credentials.
• The tool call appears in the audit log under the running user and the running user’s connection.

Pinned Connections (Workflow Authoring)

A workflow step can be pinned to a specific integration connection. This is useful when an admin builds a workflow that should always run against a particular team account, regardless of who triggers it.

Pinning is off by default at the organization level and is governed by the pinnedIntegrationConnectionsEnabled admin setting. When pinning is disabled (the default), every run of every workflow falls back to the running user’s default connection.

When pinning is enabled, Kindo enforces the following at runtime:

1. The workflow author must have USE access to the pinned connection at the time of pinning. Pinning a connection the author cannot use is rejected with a 403.
2. The running user must independently have USE access to the pinned connection. Same-organization membership is not sufficient — the running user must own the connection directly or belong to a group it is explicitly shared with.
3. If the running user does not have USE access to the pinned connection, the entire conversation turn hard-fails with PinnedConnectionUnavailableError before any tools are loaded. The agent does not silently fall back to a different connection.
4. If an admin disables pinning while runs are in flight, in-progress and subsequent runs revert to the running user’s default connection for that integration.

Practically, this means pinning acts as a routing hint, not as a credential-delegation mechanism. Sharing a pinned workflow with a teammate does not share the underlying credentials — the teammate still needs an independent USE grant on the connection through ownership or a user-group share.

Effect on Isolation

For a team using Approach 1 (group-scoped integration access):

• An org-wide agent invoking the team’s integration will fail for any user outside the team, because the runtime resolves no authorized connection for that user.
• A pinned workflow referencing the team’s connection cannot be executed by users outside the team, even if the workflow is shared with them.
• The team’s integration is never indirectly exposed through a shared workflow.

For a team using Approach 2 (individual connections):

• An org-wide agent invoking the integration uses the running user’s own connection, so downstream permissions continue to apply per user.
• A pinned workflow referencing one user’s connection cannot be executed by another user unless the connection is shared via a user group.

Verification Checklist

Before treating an isolation configuration as complete, walk through this checklist with at least one user inside the trusted group and one outside.

1. Outside-user discovery check — Sign in as a user not in the trusted group. Confirm:

   • The integration does not appear in Settings > Integrations (for Approach 1).
   • The integration’s tools do not appear in chat tool listings.
   • The integration does not appear in the agent builder’s integration picker.

2. Outside-user direct-use check — Still as the outside user, attempt to start a chat asking the AI to use a tool from the isolated integration. Confirm the AI reports no available tool.

3. Outside-user shared-workflow check — Have an admin author a workflow that uses the isolated integration. Share the workflow with the outside user. Confirm running the workflow fails with a clear credential-unavailable error rather than silently using the admin’s connection.

4. Inside-user happy path — Sign in as a member of the trusted group. Confirm the integration is visible, tools are listed, and tool calls succeed.

5. Audit log review — Open Settings > Security > Audit Log and filter by integration tool events. Confirm every successful call is attributed to a user inside the trusted group. Open an event’s Raw Data payload to confirm the connection metadata corresponds to that user’s authorized connection.

6. Re-verify after changes — Repeat this checklist whenever an admin adds a new shared connection, changes group membership, or modifies integration-level access.

Current Limitations

Kindo’s isolation primitives address the core enterprise use cases, but a few rough edges remain. Document these explicitly when sharing this guide with external security reviewers.

Limitation	What it means	Recommended workaround
No first-class “trust domain” object	Isolation is composed from RBAC overrides, group membership, and connection sharing rather than being represented as a single named boundary in the UI. There is no single screen labeled “Legal team trust domain” that shows the full isolation posture at a glance.	Use a consistent naming convention for trusted groups (e.g., Trust: Legal, Trust: Finance) and document the configuration in your security review. The Verification Checklist above is the canonical way to confirm posture.
Per-user delegated OAuth is not a first-class connection mode	Some integrations require each user to connect individually (the default behavior) while others can be served by a shared admin connection. There is not yet a per-integration toggle that forces delegated auth and rejects shared service-account connections.	For integrations where individual identity is required, instruct admins not to share their connection with any user group. Sharing requires an explicit administrator action, so the absence of shared connections is auditable from the Integration & Tool Access tab of each user group.
Admin manage vs. use distinction for connections is finer-grained than the UI surfaces	An administrator who can administer connections (delete, reconfigure) is not necessarily authorized to invoke tools against them, and vice versa. The backend enforces this split, but admin-facing surfaces do not always make the difference visible.	Treat “admin” as the strongest available control, but verify with the audit log when investigating sensitive tool calls. Inspect the Raw Data payload of tool-invocation events for the connection metadata, not just the acting user.
Connection sharing scope is per-user-group, not per-tool	When an admin shares a connection with a user group, every group member who can use the integration can use the shared connection on every tool action that integration exposes (subject to group-level tool overrides). There is no way to share a connection only for a subset of tool actions.	Use group-level tool action overrides (see Tool Action Access Controls) to restrict the tool surface available to the group as a whole, which implicitly restricts what the shared connection can do.

Relationship to Other Governance Controls

Control	Role in isolation
Tool Action Access Controls	Org-level enable/disable, per-group overrides, per-tool granularity. The mechanics behind Approach 1.
User Groups	The membership boundary that scoping is applied against. Also governs feature permissions (Ask Mode, Agent Creation, etc.) that further constrain what isolated-group members can do.
Security Controls — Integration Access	The organization-level integration toggle that serves as the baseline.
Security Controls — Audit Log	Records every tool invocation under the running user. The event’s Raw Data payload carries connection metadata, providing the audit trail required by compliance reviewers.
Governance and Controls	The framework overview that places these primitives in context.

Next Steps

• Walk through the Verification Checklist for each sensitive team in your organization.
• If you need finer-grained per-tool restrictions for an isolated group, see Tool Action Access Controls.
• For SIEM forwarding of audit events to your security operations stack, see Security Controls — Audit Log Storage.