Integrations: adapters, connection requirements, and where GembaOS sits

GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC. It is not an orchestration framework and not a gateway for model traffic, so on most stacks it is added rather than swapped in.

How a system is connected

Each existing system is wrapped by an adapter as a set of governed operations. Nothing in the system is rewritten, and the model never holds its credential: the model can only propose an operation, and GembaOS carries it out after the policy decision and, where the playbook requires it, the human signatures.

An operation can be called only when a playbook grants it. A connection with no playbook behind it is on the register, but no agent can reach it.

What every connection must show before it goes live

The Connections page in the console lists every outside system by its link material: the names of the variables it needs and whether each one is set, never a value. Beside that it shows health read from the record, the scope the playbooks grant, the vendor contract watch, and the credential fingerprints with their rotation dates.

Each connection carries a go-live checklist. Every line is decided by the configuration and the record, and none is ticked by hand:

• the variables are set;
• the real system answers, not a stand-in;
• the vendor’s contract is watched;
• a governed call is on the record;
• a playbook grants the operation;
• every playbook that writes names an accountable person;
• the write-operation sheets have no gaps;
• a rotation policy is set;
• where the data goes is declared.

For every production write a playbook grants, a sheet read off the configuration answers six questions:

1. Who calls it: the roles, the accountable person, who runs it and under whose credential.
2. What may be read.
3. When a person signs: the decision, the stamps in each band, the signals that always need a person, and how many people the authority matrix requires.
4. How the approved arguments are bound: the single-use clearance token, what is read again before the write, the allowed ranges, and who fills the idempotency key.
5. What happens on each kind of failure.
6. What the target system itself supports: version or conditional writes, read-back, a duplicate marker.

A question the configuration leaves blank shows as a gap. A limit of the target system shows as a note and is never presented as a capability.

What to prepare for a connection

In a pilot, two or three target systems are connected in weeks three and four. For each one, the sheet above is easier to fill when these are ready:

• a test environment or sandbox account of the target system;
• its interface description: an OpenAPI specification, a message layout or a file layout;
• a service account with the narrowest scope the operations need, kept in your own environment;
• which operations only read and which ones write, and who answers for each write;
• whether the system supports conditional writes, read-back after a write and a duplicate marker, because the answers decide what GembaOS reads again before writing and how a retry is kept from happening twice.

Existing assistants and agent frameworks

GembaOS works with existing assistants and agent frameworks through MCP in both directions. Outbound, a legacy system becomes a standard MCP tool that the company’s Claude Code, Copilot or Cursor can call, and every call passes the same gates. Inbound, an agent built on LangGraph, Dify or a similar framework points its tool endpoint at the GembaOS gateway and gains approvals and clearances without changing its orchestration code. The pages below describe where the seam is for each stack, in the terms that stack already uses.