MCP sidecar
The Model Context Protocol (MCP) sidecar governs tool discovery and invocation in Consul Agentic Runtime Fabric. It applies policy to tool access while backend services retain responsibility for tool business logic.
The MCP sidecar is the specialized proxy on the agent's tool-call path. Its Envoy external processor implements tool-access policy. The sidecar reads each JSON-RPC request, applies per-tool policy, and marks calls that need human approval before Envoy routes them to the tool server. To learn how model, tool, and identity paths fit together, refer to the Consul Agentic Runtime Fabric architecture.
Enterprise
Appropriate Consul Enterprise license required.
Introduction
An agent can discover a tool without having permission to invoke every operation that the tool exposes. Consul Agentic Runtime Fabric separates catalog visibility, network connectivity, delegated user authority, tool-level policy, and human approval. A successful decision at one layer does not bypass the others.
Consul configures the mesh data plane. Envoy forwards approved requests through the configured mesh path.
Deployment prerequisites
You need a valid Consul Enterprise license to use the MCP sidecar.
Configure the license in your Consul deployment, then enable the consul-ai
feature gate before enabling this component.
On Kubernetes, Consul injects the MCP sidecar into pods annotated with
consul.hashicorp.com/ai-role: ai-agent. Set the sidecar image with the
ai.agent.image Helm value.
Pull the csl-mcp-sc image alongside the other required Agentic Runtime Fabric
components. Replace <registry> with the registry path supplied for your
distribution and <version> with a compatible release tag. For Docker, run:
$ docker pull <registry>/csl-mcp-sc:<version>
For Podman, run:
$ podman pull <registry>/csl-mcp-sc:<version>
Authenticate to the registry when required and pin an approved release tag or digest in your deployment manifest. Deploy the image using the configuration supplied with that release. Pulling the image does not register tool services, configure mesh routes, or enable tool-access and human-approval policies.
Discovery and invocation
The sidecar exposes an authorized tool catalog and evaluates invocation independently. Discovery responses describe available tools. They are not credentials or durable authorization decisions. Policy can change between discovery and invocation.
For a tool call, the enforcement path considers:
- The authenticated workload making the request.
- Delegated user authority when the operation carries user context.
- The requested MCP method, tool, and applicable tool policy.
- Verified approval evidence when policy requires a human decision.
Routing and decision metadata must derive from validated request content and trusted configuration. Caller-supplied headers must not be accepted as proof of authorization or human approval.
Human approval
For a protected operation, an application approval workflow supplies a decision to an enforcement processor. The processor must verify evidence bound to the original action before allowing the request to proceed. Relevant bindings include the operation, destination, arguments, and request challenge.
A missing, expired, rejected, or mismatched approval does not authorize execution. An approval for one action must not authorize a different tool, changed arguments, or a different destination. Destination policy still applies after approval.
The application owns the human interaction. The sidecar owns enforcement on the tool-call path. It does not determine whether a human's business decision is correct.
Backend connectivity
| Backend | Governed path | Additional responsibility |
|---|---|---|
| In-mesh MCP service | Approved mesh route to the tool service. | The destination enforces its applicable identity and tool policy. |
| External HTTP MCP service | Approved route through a terminating gateway. | The terminating gateway uses trusted credential bindings and validates external TLS. |
External credential injection is distinct from delegated user authorization. A provider credential proves the terminating gateway's authority to authenticate to the external service. It does not replace the caller's permission to invoke the tool.
Operational evidence
Correlate discovery, invocation, policy decisions, approval outcomes, and backend results using request and trace context where available. Record bounded decision metadata without logging tool arguments, tool results, credentials, or approval tokens.
MCP sidecars automatically instrument supported tool exchanges without tracing SDKs or manual spans in agents or tool implementations. Applications preserve trace context across calls. Capture tool identity, argument and result evidence, and protocol errors only under the documented payload-trace privacy controls. Automatic instrumentation is not automatic redaction.
These observations support cycle detection, including repeated calls to the same tool with the same arguments and unchanged results. Asynchronous containment does not replace tool authorization or human approval.
A successful HTTP or MCP response establishes a protocol outcome, not completion of the user's workflow. Applications supply the task outcome needed for business-level analysis.
Dependencies and boundaries
- Consul and Envoy own configured connectivity and mesh enforcement.
- Participating identity processors validate delegated authority separately from workload identity.
- Applications explicitly integrate human-approval callbacks when required.
- Backend services implement tools and their business-side effects.
The MCP component owns supported topologies, sessions, protocol handling, processor ordering, and catalog aggregation behavior. Do not assume that every topology supports the same session or aggregation behavior, or that a disconnected client cancels an action already executed by a backend.