Integration
Authority integrates at the action boundary: the commit point where autonomous intent becomes a consequential operation. The implementation pattern matters less than the invariant: the action cannot reach consequence without a decision.
The action boundary is defined in Ambit Authority.
Where Authority Sits
Authority is strongest when the governed downstream system cannot be reached without a decision. That is the execution boundary.
Authority does not replace your agent runtime, API gateway, or orchestration layer. It inserts a governance decision into the path between intent and consequence, and commits evidence before execution continues.
The Placement Test
A valid integration is not defined by whether it uses an SDK, gateway, or sidecar. It is defined by the path to consequence.
- If the action can reach the downstream system without an Authority decision, governance is advisory.
- If bypass requires changing application code, gateway routing, service-mesh policy, or runtime infrastructure, governance is enforceable and auditable.
- If the evidence ledger has no decision for a state change that occurred, the absence is itself a governance signal.
The implementation pattern is negotiable. Complete mediation is not.
Pipeline Layers
Deployment has four dimensions: pipeline layer — when governance can intervene; integration pattern — how Authority is inserted; enforcement plane — what consequence surface is governed; and consequence topology — what the proposed action would cause if allowed.
Authority can integrate at multiple layers for visibility, but enforcement is authoritative only when the action cannot commit without a decision. Placement determines whether governance can be enforced; consequence topology determines what policy-visible risk the proposed action carries at that boundary.
An action usually passes through formation, transport, and execution before it reaches an external system. Each layer is useful. Only execution placement proves complete mediation.
Action Formation
High context. Not sufficient alone.
Where actions are proposed: agent runtimes, planners, SDK wrappers, and tool-call construction. This layer has rich semantic context, but it is not enough by itself because other paths can still reach the downstream system.
Transport & Coordination
Useful control. Still route-dependent.
Where actions move between components: API gateways, service meshes, tool proxies, and queues. This layer can enforce a route, but it is not always the final point of consequence.
ExecutionAuthoritative Layer
Complete mediation at commit.
Where actions commit to external systems: tools, APIs, databases, memory stores, runtimes, and outbound channels. This is the authoritative layer when downstream consequence is unreachable without Authority.
| Layer | Context Quality | Enforcement Strength | Bypass Risk |
|---|---|---|---|
| Action Formation | High | Advisory | High |
| Transport & Coordination | Medium | Partial | Medium |
| Execution | Structural | Authoritative | Infrastructure change |
Integration Patterns
Authority is placed through three common patterns: embedded SDK, centralised gateway, or co-located sidecar. The right choice depends on where the action becomes unavoidable.
SDK
Authority evaluates inside application code through a lightweight SDK call. This is authoritative when the SDK is on the only path to the consequential operation. Example: an internal workflow invokes `refund.issue` through governed application code.
Gateway
Authority evaluates at a central enforcement boundary: action gateway, tool proxy, or service-mesh entry point. The gateway carries the action to Authority, then enforces the decision. Example: a proposed refund API call is routed through the enforcement gateway before the payments service.
Sidecar
Authority runs as a co-located service beside the runtime, reachable over a local enforcement interface. This fits orchestrated environments where policy evaluation should stay near the workload. Example: a Kubernetes-hosted runtime calls the local governance service before tool execution.
Choose SDK when application code owns the action path. Choose Gateway when actions leave through a central egress path. Choose Sidecar when governed execution runs inside orchestrated runtimes. In every valid pattern, evaluation is synchronous and fail-closed: execution does not proceed without a decision, and the decision record is committed before consequence.
Enforcement Planes
Enforcement planes are defined by where actions can produce or extend real-world consequences — not by how they are implemented.
The following planes represent the surfaces through which consequential actions are expressed. Governance may operate across all of them, but enforcement is authoritative only where a consequence cannot happen without a decision.
The plane identifies the surface. The topology identifies the effect. A network boundary can carry a harmless internal telemetry event or an externally binding customer notification; a data boundary can carry a reversible read or an irreversible persistent write. Authority resolves that topology before policy decides whether the action remains admissible.
Not every system surface is an enforcement plane. Some — such as prompt filtering, output validation, and model routing — influence behaviour but operate before action formation and do not determine whether a consequential action is authorised:
Bypass Detection
When an action reaches a downstream system without passing through Authority — via a misconfigured path, a direct connection, or an ungoverned runtime — no decision record is produced. The decision ledger has no entry and the hash chain has no link. This absence is the signal: a state change without a corresponding governance decision is a detectable governance failure. Observatory monitors the decision ledger for exactly this: gaps, missing records, and sequence discontinuities.
From Enforcement to Assurance
Each decision produces a governance receipt: a tamper-evident record of the action, policy, delegation, context, outcome, timing, and ledger position.
Observatory interprets these records — generating governed traces, root-cause narratives, and assurance reports without sitting in the enforcement path.
Enforcement becomes evidence. Every governed action has a decision. Every decision has a record. Every record can be challenged later.
Integration architecture is defined by your action boundary, action classes, and governance requirements. Deployment is tailored to your environment.
See the same canonical action governed over HTTP, MCP, and A2A in the demos →
Bring one consequential action path. Ambit maps where Authority must sit for the decision to be enforceable.
Evaluate your action boundary