Consul Agentic Runtime Fabric
Consul Agentic Runtime Fabric extends Consul service mesh governance to AI agents, so 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.
Some Consul Agentic Runtime Fabric capabilities are design proposals rather than features in Consul 2.1, including automatic upstream management, intelligent circuit breaking, token-aware admission, and audit delivery. Each component page labels proposed behavior. Confirm component support before you plan a deployment.
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 proposed behavioral analysis | Correlate operational evidence and analyze application-provided 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 Gateway | 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 and KPIs | Correlate gateway decisions, usage, and application-provided outcomes. | Network success does not establish task success or model quality. |
Workflows
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 Gateway 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 and KPIs connect gateway decisions with application outcomes. The inference implementation provides metrics and tracing. The architectural audit-delivery capability is separate. Higher-order key performance indicators (KPIs) require application-defined task outcomes and suitable correlation.
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.