Integration

Where the boundary sits in your stack

The governance layer operates externally. You do not have to change the foundation model, and in most deployments you do not have to change the agent either — what changes is the path a consequential action has to travel before it becomes an operational fact.

This is not an API reference

It describes where the control point goes and what it needs, not endpoint signatures. Publishing a frozen contract for a system that has not entered production would be the same mistake as publishing an audit of one — and it would strand anyone who integrated against it. The endpoint reference ships at general availability, alongside the penetration test summary and the status page.

See assurance status

What every path has to do

However the boundary is wired in, the same six steps have to happen before an external action is released. They come from the public reference pattern in our white paper.

  1. 01

    Define the action

    Express the proposed external action, target, scope, and expected consequence as a bounded request.

  2. 02

    Resolve the principal

    Identify on whose behalf the action is requested and what authority that principal actually holds.

  3. 03

    Apply policy

    Evaluate the request against the policy and risk state valid for this decision.

  4. 04

    Require evidence

    Confirm mandatory approvals, facts, preconditions and human attestations are present and current.

  5. 05

    Issue a disposition

    Return an explicit permit, hold, escalation or block. Silence is not permission.

  6. 06

    Restrict execution

    Let the downstream system act only on an authorized disposition, then retain the decision evidence.

The four paths below differ in where that sequence runs and what it can see — not in what it decides.

Four integration paths

01

Adapters

Inside the agent runtime

The adapter wraps the agent's tool-calling surface. A proposed call is submitted for a disposition and only released if permitted.

Where it sits
Between the agent framework and the tools it can invoke.
Best when
You own the agent code and want the shortest path to a governed pilot.
You provide
  • One policy domain to start with
  • A source for the evidence that domain requires
  • A named human owner for escalations

Mediation is only as complete as the adapter's coverage. Any tool the agent can reach outside the adapter is ungoverned, which is the failure this whole layer exists to prevent.

02

Middleware

In the request path

The boundary runs as a service in the network path, so consequential calls cross it regardless of which agent or language produced them.

Where it sits
At a service or network boundary, ahead of the systems that carry consequence.
Best when
Several agents, several teams, or agent code you do not control — including vendor agents.
You provide
  • Routing that forces consequential calls through the boundary
  • Identity propagation, so the principal is resolvable
  • Deployment environment and its assurance obligations

Complete mediation becomes a network property. If a service can reach a credentialed system directly for latency reasons, that route is the gap.

03

Tool brokers

The model never holds the credential

The agent asks a broker to perform an operation. The broker holds the authority and the credentials, and acts only on an authorized disposition.

Where it sits
Between the agent and any credentialed or externally-effective system.
Best when
Credential sprawl and excessive agency are the risks that worry you most.
You provide
  • A registry of permitted operations
  • Short-lived, task-scoped credentials the broker can issue
  • Revocation path and its owner

The broker becomes a high-value target and a single point of failure. It needs the operational treatment that implies, not just the architectural diagram.

04

Hardware interfaces

In series with the actuator

Governance silicon sits in the actuation path itself. State is held on-die and no network interface is operative at decision time.

Where it sits
On the device, physically in series with the output that creates the consequence.
Best when
The consequence is physical or irreversible, or the device must keep governing while offline.
You provide
  • The physical and electrical integration point
  • A provisioning path for authenticated policy state
  • Field-of-use and volume expectations

This is a patent and technical-development portfolio, not a shipping part. Deployment requires independent validation, security engineering, accreditation and operational authorization.

Choosing between them

AdaptersMiddlewareTool brokersHardware
Agent code changesYesNoSomeNo
Language-agnosticNoYesYesYes
Mediation guaranteed byAdapter coverageNetwork routingCredential holdingPhysical series
Governs while offlineNoNoNoYes
Holds credentialsNoNoYesNo
Typical first pilotYesYesNoNo

Most first deployments are an adapter or middleware around one controlled action. Brokers and silicon follow once the boundary itself has been proven on something small enough to stop.

Start with the boundary, not the wiring

Which of these fits is an output of the Boundary Assessment, not an input to it. The assessment maps one workflow, its authority model, the policy and evidence it requires, and the threat boundary — and the integration path falls out of that. Choosing the wiring first tends to produce a governed path that the consequential actions can route around.

See how we priceRead the white paperRead the FAQ