Platform · Connectors
1000+ connectors.
One controlled layer.
AI is only as useful as the systems it can reach — and only as safe as the way it reaches them. Leapforce gives AI coworkers approved, scoped, logged access to your CRM, ERP, documents, tickets, and data — through a registry IT curates, not credentials employees improvise.
coworkers
Salesforce
Oracle ERP
SAP ERP
Google
Office 365
Slack
Box
Asana
Why a registry, not a pile of integrations
The dangerous part of AI isn't the model. It's what the model can touch.
A chat window that can't reach your systems is low risk and low value. The moment AI connects to the CRM, the ledger, or the document store, both go up sharply — and that is exactly where ungoverned adoption is heading. Security researchers now flag OAuth-connected agents with persistent data access, unvetted MCP servers exposing internal APIs, and sprawling API tokens as the fastest-growing AI threat surface, precisely because each one is a connection nobody centrally approved.
The traditional answer — review every connection one at a time — collapses under volume. When every department wants ten integrations, the review queue becomes the reason teams go around IT in the first place.
A curated registry resolves the tension: connectors are vetted once, published with scoped permissions, and granted by role in minutes. Employees get self-serve speed; IT approves categories and scopes instead of tickets. The catalog spans CRM, ERP, email and calendar, documents, projects, finance, support, data warehouses, and internal tools.
How it works
From request to governed connection.
Five stages turn a connector request into an approved, scoped, logged connection — and a revocable one.
Curate
IT approves the catalog
Admins choose which connectors and MCP tools exist for the company, per team — version-pinned and allowlisted, so an upstream change never silently alters what an agent can do.
Scope
Permissions are narrowed
Each grant carries the minimum scope: read-only where reading is enough, one pipeline instead of the whole CRM, drafts that require human send. Least privilege is the default, not an option.
Grant
Roles receive access
Connectors attach to roles from your directory. A support hire gets the ticket connector on day one; nobody emails around credentials to make it happen.
Broker
Calls flow through the gateway
Every connector call is authenticated, policy-checked, and executed with vaulted credentials — the agent never holds the system's password, only a short-lived scoped token.
Record
Every action is logged
Reads and writes land in the audit trail with actor, agent, tool, and data touched — so "what did AI do in our CRM last month" is a query, not an investigation.
Capabilities in depth
What “governed connector” actually includes.
Every connector in the registry ships with the same controls — here is what that phrase actually covers.
Pre-built catalog, enterprise depth
Over a thousand integrations across the software companies actually run — Salesforce and the CRM field, Oracle and SAP on the ERP side, Google Workspace and Microsoft 365, Slack, Box, Asana, ticketing, data warehouses, and the long tail of departmental tools.
Version-pinned MCP & tool registry
Tools and MCP servers are published into the registry at a specific version. Upgrades are reviewed and rolled out deliberately — an upstream maintainer can't change an agent's capabilities overnight.
Action-level scoping
Scopes go below the app to the action: search, read, draft, write, send, export — each grantable separately. The triage coworker that reads tickets and drafts replies simply has no export action to misuse.
Credential brokering
System credentials live in the vault and are exchanged for short-lived tokens per call. Rotations happen centrally; a leaked agent config exposes nothing durable.
Custom enterprise connectors
Internal systems, regional tools, and unusual vendors get first-class connectors built on request under the managed plan — delivered into the same registry with the same scoping and logging.
Human-in-the-loop actions
Sensitive actions can be published as approval-gated: the AI prepares, a named human confirms, the trail records both. Useful for sends, payments, and anything customer-visible.
Data-class awareness
Connector fields can be tagged by sensitivity, feeding the gateway's masking and local-routing decisions — payroll fields from the HR connector never reach an external model, by construction.
Usage-driven review
Connectors report usage per team and agent. Unused grants surface for removal; heavily used ones justify deeper scopes — access evolves on evidence instead of guesswork.
In practice
What departments do with governed connections.
Coworkers read pipeline context from the CRM to draft outreach and briefs — scoped to the rep's own accounts, with writes limited to notes and drafts.
ERP connectors expose reporting views, tagged sensitive so summaries run on local models. Closing checklists pull live numbers instead of pasted spreadsheets.
The ticket connector grants read and draft; sends stay human-approved until the team decides otherwise. Every AI-drafted reply is attributable.
Project and document connectors let coworkers assemble status reports across tools — read-only, so the automation can inform but never reorganize.
Existing one-off integrations and personal OAuth grants migrate into the registry, where they finally show up in access reviews and audit queries.
Rollout guide
Connect the top five systems first.
Phase 1 — Inventory what's already connected: OAuth grants, API keys, and integrations living outside IT's view.
Phase 2 — Publish the five systems that carry most work — usually CRM, email/calendar, documents, tickets, and the ERP's reporting views — with conservative scopes.
Phase 3 — Migrate existing shadow integrations into the registry, retiring their standalone credentials as they move.
Phase 4 — Widen scopes where usage proves value, and commission custom connectors for the internal systems that matter.
Evaluation checklist
Questions for any connector layer.
Are connector versions pinned, or can upstream changes alter behavior silently?
Can scopes go to the action level, or only app-level on/off?
Who holds the credentials — the vault, or every agent's config?
Can sensitive fields be tagged so masking and local routing follow the data?
Are approval-gated actions supported for sends, payments, and deletes?
Does every read and write land in an audit trail with an owner?
What happens to grants when a person leaves or a team dissolves?
Questions we hear
Connectors — frequently asked.
Request it. Common gaps are prioritized into the catalog; internal or unusual systems become custom connectors under the managed enterprise plan. Either way it lands in the same registry with the same scoping, logging, and review behavior.
Yes — MCP tools are first-class registry entries: allowlisted per team, version-pinned, scoped, and logged like any connector. The registry exists precisely because unvetted MCP servers are one of the fastest-growing AI risk surfaces.
Read-only is the recommended starting scope for most connectors. Writes are added action by action as trust and evidence accumulate — and destructive actions can stay approval-gated indefinitely.
Connector updates are versioned and reviewed before rollout. If an upstream API breaks compatibility, the pinned version keeps working where possible and the change is flagged to admins — agents don't inherit surprises.
Automation platforms move data between apps on schedules and triggers. This layer governs what AI — people prompting models, and agents acting autonomously — may reach and do, with identity, scoping, masking, and audit built in. They can coexist; they solve different problems.
Yes. The registry is per-team: Support sees ticketing and knowledge tools; Finance sees ERP views; nobody sees connectors their role doesn't include. The company catalog is the union, curated centrally.
Third-party marks identify the systems Leapforce connects to; all trademarks belong to their owners. Connector availability is disclosed per system, honestly, including build status.
In the audit trail with actor, agent, action, and data touched — queryable and exportable to your SIEM. See Observability & Audit for the full trail.
Third-party names and logos identify the systems Leapforce connects to; all trademarks belong to their owners. Leapforce is in active development — per-capability build status disclosed honestly on request.