Consul Agentic Runtime Fabric
Consul Agentic Runtime Fabric extends Consul service mesh governance to AI agents, so that their calls to large language models (LLMs), other agents, and Model Context Protocol (MCP) tools travel over authenticated, policy-controlled paths.
Consul Agentic Runtime Fabric components run in the Consul control plane and data plane, while applications and external systems keep responsibility for planning, business logic, and user identity.
Enterprise
Appropriate Consul Enterprise license required.
Introduction
An AI application can call a model, delegate work to another agent, and invoke tools on behalf of a user. Each interaction requires a distinct decision: whether the workload can connect, whether the user has delegated authority, whether the requested model or tool is permitted, and whether the operation requires human approval.
Consul Agentic Runtime Fabric separates these decisions across gateways, identity integrations, application-local development libraries, and observability components. Consul workload identity and service intentions remain the foundation for mesh connectivity. They do not replace delegated user authorization or application policy.
Consul Agentic Runtime Fabric builds on Consul service registration, workload identity, service intentions, and proxy configuration. These mechanisms establish governed network paths. Additional processors interpret model and tool requests, integrate delegated user authority, and apply component-specific policy.
An AI application remains responsible for planning work, choosing operations, and interpreting results. Network authorization does not establish that an operation is appropriate for a user's task or that a successful response meets the application's requirements.
Architecture
The following diagram illustrates a travel application with agent-to-agent, model, and tool request paths, alongside catalog registration and telemetry connections. Click the diagram to view it at full size.
The named providers and telemetry integrations illustrate the topology rather than establish release support. Component availability and security boundaries follow the descriptions on this page and the linked component documentation.
Architectural layers
| Layer | Responsibility | Boundary |
|---|---|---|
| Consul control plane | Maintain service and policy configuration and supply the resulting proxy configuration. | Does not execute agent workflows or issue user access tokens. |
| Envoy data plane | Enforce configured mesh connectivity, forward requests, and perform configured routing and retries. | Network reachability does not replace tool policy or delegated-user authorization. |
| Gateway and identity processors | Interpret supported protocols, transform payloads, and participate in policy and identity processing. | Processors operate within trusted proxy configuration rather than accepting caller-selected routes or credentials. |
| Application-local Development Kit | Observe local upstream connectivity, handle approval callbacks, and coordinate component lifecycle. | Does not install mesh routes or grant authorization. |
| External identity and credential systems | Customer identity and access management (IAM) issues delegated tokens. Vault supplies external provider credentials. | User delegation and provider authentication remain separate trust relationships. |
| Observability and Agentic Analytics | Automatically capture supported proxy interactions, correlate operational evidence, and detect unproductive repetition. | Applications supply business outcomes; telemetry does not prove task success, and delayed analysis cannot prevent every unsafe first action. |
Consul and Envoy own mesh configuration and transport. Applications explicitly integrate the Development Kit and supply the workflow semantics that network components cannot infer.
Components
| Component | Responsibility | Architectural boundary |
|---|---|---|
| AI Inference Gateway | Govern model access, routing, provider translation, usage controls, and data protection. | Honor-permitted explicit model choices and caller-approved fallback. |
| MCP sidecar | Govern Model Context Protocol (MCP) tool discovery and invocation. | Catalog visibility does not grant permission to invoke a tool. Backends own tool business logic. |
| Identity plane | Carry destination-scoped delegated user authority alongside workload identity. | Customer identity and access management (IAM) remains the token issuer. |
| External credential injection | Authenticate approved external HTTP MCP and API calls at the terminating gateway. | Callers cannot choose secret locations or override trusted destination bindings. |
| AI observability | Correlate operational signals, model attribution, and audit requirements. | Telemetry delivery and content capture require explicit controls; traces alone are not a complete audit ledger. |
| Auto-instrumentation | Automatically instrument supported model and tool traffic and supply inputs for operational metrics and business KPIs. | No application tracing SDK is required; applications preserve trace context and supply business outcomes that proxies cannot establish. |
| Cycle detection | Use Agentic Analytics findings to open agent-scoped circuits for unproductive repetition. | Repeated arguments alone do not prove a cycle; asynchronous enforcement cannot undo completed actions. |
Workflows
The following workflows show how the components work together to govern model access, tool access, and delegated identity, and to observe and contain agent behavior.
Govern model access
An application sends a supported inference request through its mesh path to the AI Inference Gateway. Processing before routing resolves workload identity, validates the request, and applies configured request-side data protection.
Envoy selects an eligible backend using Consul-supplied configuration. Processing after routing translates the request for that provider, normalizes supported responses, and captures usage. The external processor does not independently choose routes or run the retry loop.
Operator policy constrains eligible models. The architecture requires permitted explicit model choices and caller-approved fallback to be respected. Retry capability does not itself authorize model substitution. Requested-model and served-model attribution connect the response to operational evidence.
Govern tool access
The MCP sidecar governs Model Context Protocol (MCP) discovery and invocation. Its enforcement path combines workload identity, delegated user authority when present, and tool policy. Catalog visibility does not grant invocation permission.
When policy requires human approval, an application callback supplies a decision and a separate enforcement processor verifies evidence bound to the original action. Approval does not replace destination authorization. Backends retain ownership of tool business logic and side effects.
Approved in-mesh tool calls use configured mesh paths. External HTTP MCP calls use a terminating gateway with external credential injection. The matched route supplies a trusted credential binding, the local credential runtime supplies a usable Vault-backed credential, and the gateway verifies external TLS before forwarding.
The route and its credential must both be usable. Callers cannot select secret locations, override destination bindings, or direct a provider credential to another host.
Delegate user identity
On-behalf-of (OBO) delegation carries user authority alongside Consul workload identity. Customer IAM remains the token issuer.
The caller-side identity processor exchanges user context for authority scoped to the next destination. The destination-side processor verifies that authority before destination policy consumes its claims. A subsequent outgoing call requires authority appropriate to the next hop, not unrestricted reuse of the previous token.
Workload TLS credentials and OAuth signing credentials have separate lifecycles. Signing material stays isolated from application configuration. Neither OBO delegation nor external credential injection defines managed-model authentication.
Investigate operational outcomes
AI observability connects operational signals across model and tool calls through trace correlation and model attribution. Metrics, traces, and audit evidence have distinct delivery and privacy requirements. The architectural audit-delivery capability remains separate from ordinary telemetry.
Trace calls and derive metrics
The AI Inference Gateway and MCP sidecars are the specialized proxies that automatically instrument supported model and tool exchanges. Applications do not initialize tracing SDKs or emit spans for these observations. They preserve trace context across calls so the proxy-generated evidence forms a correlated workflow trace. Aggregate this evidence into operational metrics using defined populations and time windows. Higher-order key performance indicators (KPIs) also require application-defined outcomes. Content capture remains subject to privacy and retention controls. To set it up, refer to Configure auto-instrumentation.
Contain unproductive repetition
Cycle detection analyzes repeated workflow steps and their results. An agent repeatedly calling the same tool with the same arguments and unchanged results can produce a cycle finding. Consul uses the finding through behavior policy to open the affected agent's circuit and reject subsequent applicable requests. Analysis runs asynchronously and supplements synchronous authorization and usage controls. To set it up, refer to Configure cycle detection.
Shared security boundaries
- Authenticate workloads and validate delegated user authority separately. Their credentials, policies, and lifecycles are distinct.
- Keep model-provider authentication separate from OBO delegation and external credential injection.
- Bind human approval to the original action. Approval evidence does not replace destination authorization.
- Treat request identifiers as correlation values, not identities or authorization evidence.
- Treat telemetry as operational evidence, not a durable audit store or billing ledger without additional delivery and retention controls.