Integrations
Connect the AI and enterprise systems you already run
AI platforms, agent frameworks, enterprise applications, data systems and identity providers. Every entry states plainly whether it is available today.
Two kinds of category
- 2 with nothing to support
- Frameworks and models. Governed at the boundary, so there is no per-target work and no support matrix.
- 3 where it varies
- Enterprise, data and identity. A connector is real work, so every entry states where it stands.
Why this is not a logo grid
For two of these five categories, there is nothing to support.
That sounds like a gap and it is the opposite. Because OpsAI attaches at the boundary an AI system calls out through, an agent built in LangGraph and one you wrote by hand are governed identically — so there is no per-framework work, and an availability badge beside a framework name would imply work that does not exist.
- AI platformsnothing to support
- A model reached over an API is governed the same way whoever serves it. The routing rule names a requirement; the provider is what satisfies it.
- 6 listed
- Agent frameworksnothing to support
- Governance attaches where an agent calls out, not inside its control flow. There is nothing per-framework to build, which is why a framework you wrote yourself is on the same footing as a popular one.
- 8 listed
- Enterprise systemsavailability varies
- A connector holds a credential and knows the action vocabulary of one system. That is real per-system work, so availability genuinely varies.
- 12 listed
- Data systemsavailability varies
- Governing a read means understanding how the source is queried and where a result may be written. Per-source work, and the same honest variation.
- 7 listed
- Identity providersavailability varies
- OpsAI reads people from your directory rather than being one. Each provider exposes its groups and its OAuth grants differently.
- 4 listed
- The consequence
- You do not adopt a framework, rewrite an agent, or wait for a connector before governing the AI you already run. Where a connector genuinely is required, the catalogue says so rather than implying otherwise by omission.
The shape of the catalogue is an argument about where a control belongs.
A product that needed a framework adapter would have a long integrations page and a governance gap for every framework it had not reached yet. This one has a short page and no such gap, and the short page is the evidence.
Where a connector is real work
Three states, and the unavailable ones stay on the page.
Enterprise, data and identity each need a connector that holds a credential and knows one system's action vocabulary. That varies, so every entry says where it stands — including the ones nobody has started.
- available
- Governed today, with the action vocabulary of that system.
- in progress
- Being built. Partially usable, and the gap is named on the entry.
- not yet
- Not started. Reachable only through a generic connection, if at all.
Targets listed
37
across five categories
Categories needing per-target work
3
enterprise, data, identity
Not yet fully available
4
listed, not hidden
Connected in the sample estate
11
a separate fact from support
IllustrativeAn illustrative catalogue for the OpsAI sample estate.
What is not available today
- SAPin progress
- Document posting and master-data changes. The action vocabulary is large and being worked through module by module.
- Microsoft Dynamicsnot yet
- Not started. Reachable today only through a generic HTTP connection, which governs the call but not the action semantics.
- BigQueryin progress
- Reads work today; the residency metadata that a data-protection review asks for is still being wired.
- Databricksnot yet
- Not started. A notebook that calls a model and writes a table is squarely in scope, and this is the gap most worth closing next.
The five categories
Each one answers a different question about the same action.
Which model answered it, what proposed it, what it changed, what it read, and whose authority it ran under. The categories are not a taxonomy of vendors — they are the parts of one decision.
AI
Connect models from Anthropic, OpenAI, Google and the other major providers alongside the internal ones you host yourself, and govern them through one layer.
Agents
Bring agents built with LangGraph, CrewAI, AutoGen, OpenAI Agents, MCP or your own framework under control without changing how they were built.
Enterprise
Govern what AI is allowed to change in the systems that hold your real state — SAP and Salesforce through to ServiceNow, Jira, GitHub and Slack.
Data
Put policy between AI and PostgreSQL, MySQL, MongoDB, Snowflake, BigQuery and S3, so a data request is authorized before it is answered.
Identity
Use Okta, Microsoft Entra or Google Workspace as the source of truth for who a person is, and tie every AI action back to one of them.
A generic connection covers anything not listed.
An HTTP connection governs the call — who made it, under whose authority, with what scope, recorded either way. What it cannot do is understand the action semantics of that system, so a bound can constrain the request but not reason about what the request means.
That is a real difference and worth being clear about: a purpose-built connector knows that a refund has an amount and a ceiling. A generic one knows a POST happened.
Asking for one
If a system you need is not yet or absent, say so. The catalogue’s order is driven by what organizations are actually trying to govern, and the honest rows above exist so that conversation starts from the real position.
Where to start
Start with the system that would hurt most if AI changed it wrongly.
Not the easiest connector. The one holding money, a ledger, or customer records — because that is where a bound earns its keep and where the record you get back is worth having.