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.
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.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.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: 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.
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.