Tool Action Access Controls

Kindo allows administrators to control exactly which integrations and tool actions are available to users and AI agents. These controls operate at two levels — organization-wide defaults and per-user-group overrides — giving you fine-grained governance over what AI can do on behalf of your users.

Why Tool Action Access Control Matters

When AI agents act on behalf of users, they can read data, create records, send messages, and modify systems through connected integrations. Without access controls, any user with an integration connection could invoke any tool action that integration exposes.

Tool action access controls let administrators:

• Restrict sensitive actions — Block specific tool actions (e.g., deleting records, sending emails) while allowing read-only operations
• Scope access by team — Give the engineering group access to GitHub and Jira tools while limiting the marketing group to HubSpot and Slack
• Enforce least privilege — Start with access disabled by default and explicitly enable only what each group needs
• Maintain compliance — Ensure AI agents operate within the same access boundaries as the users they represent

How It Works

Kindo uses a hierarchical permission model to determine whether a user can invoke a specific tool action:

1. Organization defaults set the baseline for all users
2. User group overrides refine access for specific teams
3. Individual user policies allow personal approval preferences

Permission Evaluation Order

When a user (or an agent acting on their behalf) attempts to use a tool, Kindo evaluates permissions in this order:

1. Is the integration enabled at the org level? If the organization has disabled the integration entirely, access is denied for all users regardless of group settings.
2. Is the specific tool enabled at the org level? Organizations can disable individual tools within an enabled integration.
3. Does the user’s group grant access? If org defaults deny access, a user group can explicitly grant it. If org defaults allow access, a user group can explicitly revoke it.
4. Does the user have a personal tool policy? Users can set individual tools to auto-approve or block, overriding group defaults for their own sessions.

Multiple Group Membership

When a user belongs to multiple groups, the most permissive rule applies — if any group grants access to a tool, the user can use it.

Example:

• Organization has Jira access disabled by default
• User A belongs to the “Engineering” and “Analytics” groups
• Engineering group has Jira access enabled
• Analytics group does not have Jira access enabled
• Result: User A can use Jira tools because the Engineering group grants access

Configuring Organization Defaults

Organization defaults define the baseline access policy for all users.

Note

You must be an Administrator to configure these settings.

1. Open Settings — Click the gear icon to open the Settings panel.

2. Navigate to Security — Select Security from the left sidebar, then select the Integration & Tool Access tab.

3. Set default access policies — At the top of the panel, configure the default behavior:

   • Default Integration Config Access — Whether new integrations are accessible by default when added to the platform. Set to Off to require explicit enablement.
   • Default Tool Access — Whether new tools from enabled integrations are accessible by default. Set to Off to require each tool to be individually enabled.

4. Configure per-integration access — The table lists all available integrations. Toggle each integration On or Off to control organization-wide availability.

5. Configure per-tool access — Expand an integration to see its individual tools. Toggle specific tools On or Off to allow or block them across the organization.

Tip

For maximum security, set both default access policies to Off and explicitly enable only the integrations and tools your organization needs. This follows the principle of least privilege.

Configuring User Group Access

User groups allow you to define different access policies for different teams.

1. Open Settings — Click the gear icon to open the Settings panel.

2. Navigate to User Groups — Select User Groups from the left sidebar. You will see a table of all user groups in your organization.

3. Select a group — Click a user group name to open its settings.

4. Open Integration & Tool Access — Select the Integration & Tool Access tab.

5. Configure group-level overrides — The table displays integrations and tools with their current access status. Toggle access for each integration or individual tool to override the organization default for this group.

Creating a User Group

1. Navigate to Settings > User Groups.
2. Click Create Group.
3. Enter a group name and optional description.
4. Add members by entering their email addresses.
5. Configure the group’s integration, tool, and model access policies.

Managing Group Members

From the Members tab of a user group, administrators can:

• Add individual members via the dropdown selector
• Add multiple members by entering comma-separated email addresses
• Remove members from the group

Shared Integration Connections

In addition to controlling which tools are accessible, administrators can share specific integration connections with user groups. This allows team members to use a shared connection (e.g., a team Jira account) without each user needing to set up their own.

Shared connections appear in the Shared Integrations section of a user group’s Integration & Tool Access tab. Administrators can add or remove shared connections from this panel.

User-Level Tool Policies

Individual users can configure personal tool approval preferences that apply to their own sessions:

• Auto-Approve — Tool calls execute automatically without confirmation
• Block — Tool calls are blocked regardless of organization or group settings

Users set these preferences from within a chat session by configuring tool approval settings for each available tool. A user blocking a tool at the personal level overrides any group or organization allowance for that user only.

Built-In Tool Controls

Beyond integration-based tools, Kindo provides organization-level controls for built-in capabilities:

• Sandbox Network Access — Controls whether code execution sandboxes can access external networks
• Web Search — Controls whether AI agents can perform web searches

These are configured in the Integration & Tool Access section of the Security settings.

Relationship to Other Governance Controls

Tool action access controls work alongside Kindo’s other governance features:

Control	Purpose
Tool Action Access	Which tools and actions are available to which users
Model Access Controls	Which AI models users can access (Security Controls)
DLP Filters	Scan and redact sensitive data in requests and responses (Governance)
Audit Logging	Record all tool invocations and actions (Security Controls)

DLP filters can be configured at both the organization and user group level, and apply to model interactions independently of tool access controls. Audit logging captures all tool invocations regardless of how access was granted.

Common Scenarios

Scenario: Restrict AI to read-only operations

An organization wants AI agents to read data from integrations but not create, update, or delete records.

1. Set Default Tool Access to Off at the organization level.
2. For each integration, expand the tool list and enable only read-oriented tools (e.g., list_issues, get_document, search_contacts).
3. Leave write-oriented tools disabled (e.g., create_issue, delete_record, send_message).

Scenario: Team-scoped integration access

Different departments need access to different integrations.

1. Set Default Integration Config Access to Off at the organization level.
2. Create user groups for each department: “Engineering”, “Sales”, “Support”.
3. In the Engineering group, enable GitHub, Jira, and PagerDuty integrations.
4. In the Sales group, enable Salesforce and HubSpot integrations.
5. In the Support group, enable Zendesk and Slack integrations.
6. Users only see and can use the integrations enabled for their group(s).

Scenario: Default-allow with targeted restrictions

An organization wants most tools available but needs to block a few sensitive actions.

1. Set Default Tool Access to On at the organization level.
2. Disable specific high-risk tools (e.g., delete_repository, send_bulk_email) at the organization level.
3. These tools are blocked for all users regardless of group membership.

Verification

To confirm tool action access controls are working:

1. Check as admin — Navigate to Settings > Security > Integration & Tool Access and verify the expected integrations and tools show the correct enabled/disabled status.
2. Check group settings — Open each user group and verify the Integration & Tool Access tab shows the intended overrides.
3. Test as user — In a chat session, verify that only the expected tools appear when the AI agent lists available actions. Tools that are disabled should not appear.
4. Review audit logs — Check Settings > Security > Audit Log for tool invocation events to confirm that access controls are being enforced.

Troubleshooting

User cannot access a tool they should have access to

1. Verify the integration is enabled at the organization level. If the integration is off, no group-level override can grant access to its tools.
2. Verify the specific tool is enabled at the organization level or in the user’s group.
3. Confirm the user is a member of the correct group. Check under Settings > User Groups > [Group] > Members.
4. Check if the user has set a personal Block policy on the tool, which overrides group and org allowances.
5. Verify the user has an active integration connection. The user (or a shared connection from their group) must be connected to the integration.

User can access a tool they should not have access to

1. Check if the user belongs to multiple groups. Access is granted if any group allows it.
2. Verify the organization default is not set to allow. If Default Tool Access is On, tools are available unless explicitly disabled.
3. Review the specific tool’s status in all groups the user belongs to.