Skip to main content
The Controls section of the admin panel governs what agents can reach — down to the individual tool.

Integrations & Permissions

Every integration (240+) can be tuned per tool:
  • Tools are grouped into read-only and write/delete — so you see at a glance what’s harmless and what acts in your systems.
  • Each tool can be allowed or blocked individually, and scoped to everyone or specific groups.
  • Whole integrations can be moved to a Restricted section — usable only on request.
The Integrations & Permissions page showing an integration's read-only and write tools, each individually allowed or blocked, with the Restricted section above the list of all integrations

Per-integration, per-tool control: read-only vs. write tools, allowed audiences, restricted integrations.

Tool Requests

When someone needs a restricted tool, they don’t email IT — they request it in Dataleap, and admins approve or reject with one click. Every request keeps its status, so decisions are documented. Filter the list by status with All, Open, Accepted, Rejected, and Stale.
The Tool Requests page in Workspace Settings, with the admin sidebar, filters for All, Open, Accepted, Rejected and Stale, and a table of member requests for tools showing each tool, its status, and the time

Access requests with a one-click approve/reject workflow.

Integration Activity

The audit trail: every tool call across the organization, live — which integration, which tool, which agent, executed as whom, and whether it succeeded. Filterable by time range, integration, status, and user. Your security team can also pull this record into its own tools, such as a SIEM. Create an API key with the Integration activity · Read scope, as described in Create a key. The key reads each tool call as metadata only, never the tool’s input or output.
The Integration Activity page with an activity chart and a table of tool calls showing integration, timestamp, tool, agent, who it ran as, and success status

Every tool call in the org — filterable, with success/failure status.

Custom integrations

Beyond the built-in integrations, admins can bring their own tools to agents on the Custom integrations page. It has two sections: MCP servers and APIs.
The Custom integrations page with an MCP servers list and an APIs list, showing tool counts, connections, credential types, and enabled or disabled status

The Custom integrations page: your MCP servers and your APIs, each with its own add button.

MCP servers

Add custom MCP servers (OAuth or bearer token) with Add MCP server. Internal tools become agent-usable, with synced tool lists and per-server enable/disable.

APIs

If your organization has its own HTTP API with an OpenAPI spec, you can turn it into agent tools without building an MCP server first. Click Add API and work through four steps:
1

Spec

Enter the Spec URL, or choose Paste spec and paste it in, then click Load spec. Swagger 2.0, OpenAPI 3.0, and OpenAPI 3.1 work, as JSON or YAML. A pasted spec isn’t stored, so you paste it again whenever you resync.
2

Connection

Pick a Credential type: OAuth2 client credentials, API key in a header, API key in a query parameter, Basic authentication, or Bearer token. Enter one credential for the whole organization, list the Allowed hosts agents may call, and test it. The secret is write-only: you can replace it later, but nobody can view it again.
3

Tools

Choose which operations agents may call. Describe what agents should do with the API and click Suggest with AI for a proposed selection with names and descriptions, or pick operations yourself. Check each tool’s name, description, and read or write mode before you continue.
4

Review

Give the API a Name, a Description, and optional Notes for agents, such as how paging works or where IDs come from. Then click Create API integration.
Members never see the credential. When an agent needs the API, they connect through a Connect dialog that asks for no secret, because your admins manage it. From then on its tools follow the same rules as any other integration: Integrations & Permissions, Tool Requests, and Integration Activity all apply. Your organization looks after its custom integrations, not Dataleap. When one of their tools fails, members are told to ask their workspace admins. Each API has its own page with Tools, Connection, and Settings tabs, where you edit tools, test or replace the credential, and check the spec for changes.
Two governance layers from elsewhere complete the picture: the org-wide system prompt (rules every agent follows, regardless of tools) and service accounts in team spaces (scoped access that survives personnel changes).

Connect your tools

The builder side: how agents get their connections.

FAQ

The questions builders actually ask.