How the CLI and MCP path is wired

On August 13, 2026, we published How the agent is wired to walk the path a tool call takes inside T6X. This post is the narrower companion to that one: what changes when the operator is outside the platform, using a CLI agent or another MCP client.

The short answer is that the protocol changes, but the controls do not.

An external assistant still reaches the same governed command surface. It does not get a second API, a weaker approval path, or direct access to credentials. MCP is only the connector at the edge. The real control points are still identity, the effective tool surface, the approval gate, server-side credential brokering, and the audit chain.

The external path

For an assistant outside the platform, the path looks like this:

CLI agent or MCP client
  -> bridge token
  -> MCP bridge endpoint
  -> tenant and agent resolution
  -> effective tool surface
  -> approval gate for sensitive calls
  -> execution
  -> hash-chained audit trail

That is the first point to keep in mind: the external assistant does not call the business system directly. It calls into the same governed host that the rest of the platform uses.

At the bridge boundary, tool names are namespaced as <serverSlug>__<toolName>. The current seed bridge accepts Authorization: Bridge <token>, verifies the token, resolves the referenced agent, restores tenant context on the server side, and only then lists or calls tools.

So even for a CLI-driven session, the interesting question is not “does it speak MCP?” The interesting question is “what does the host allow this identity to do once it arrives?”

Identity arrives before tools

The CLI product page says your own assistant signs in as itself, with single sign-on or a scoped key, under the same rules as everyone else. That matters because governance starts with identity, not with a prompt.

In the bridge path, the assistant presents a bridge token. The server verifies it and resolves the associated agent record before dispatch. If the token is invalid, or it points at an agent that no longer exists, the call stops there. If the agent belongs to a tenant, the bridge re-enters that tenant context before doing any work.

That is what prevents the external connector from becoming a side door. The assistant is not trusted because it is “your AI”. It is constrained because the host re-establishes identity and scope before a tool becomes callable.

The surface stays governed

Once the assistant is in, it still does not get a free-form tool bag.

T6X resolves an agent’s effective surface from the host side. For view-bound agents, the runtime formula is the view’s catalogue plus any explicit allowlist, minus denies, intersected with the caller’s own permissions. The important point is structural: the platform computes the surface, the model does not.

The same distrust applies to MCP tool effects. An MCP server can describe its own tools, including whether it claims they read or write. T6X does not treat that claim as enough. The runtime effect comes from the operator catalogue, and an unknown effect is denied rather than assumed harmless.

That closes a common failure mode in agent systems. A destructive tool does not become read-only because a server labeled it that way.

The operator surfaces around MCP are governed too. In the current seed, the GraphQL write side for MCP server definitions and attachments is admin-only, and the privileged path for direct tool invocation is narrower still. So even the act of defining or attaching external MCP capability is behind role checks.

Secrets stay on the server side

The strongest security property in this path is that the model does not hold the real integration credential.

The concrete proof already exists in the kubectl end-to-end harness. The agent asks to run the kubectl tool with {{vault.KUBECONFIG}}. The audit row records that placeholder, not the kubeconfig itself. The real secret is substituted server-side by the vault-aware bridge path before the external MCP server receives the call.

That means the assistant can request work that needs a credential without ever seeing the credential’s value. The model gets the placeholder, the host resolves it, and the audit trail keeps the original placeholder visible for later review.

This is the same design described in the earlier wiring article, only now it is seen from the external assistant path instead of from an in-platform agent turn.

Approval and audit still matter more than the protocol

If the assistant reaches a sensitive tool, the important control is still not “was this call made from a CLI?” It is “what effect does this tool have, and was it approved under policy?”

The CLI pillar promise is that preview, least privilege, and confirmation on sensitive changes apply to the assistant exactly as they apply to a person. That promise only matters if the trail is the same too. In T6X, the goal is one audit story, not one for humans and another for external agents.

Every call still lands on the same tamper-evident record. The protocol at the edge can vary, but the record that matters is the one inside the governed host.

What is implemented today

The current repository already shows the important pieces of this path:

• CLI product copy that explicitly positions MCP as the way to bring your own assistant to the command surface.
• Bridge configuration and deployment wiring for the MCP bridge base URL, token secret, and audit signing secret.
• Bridge code that verifies Bridge tokens, resolves the target agent, and re-establishes tenant context before tool listing or dispatch.
• MCP policy code that separates ordinary write operations from narrower privileged ones.
• End-to-end harness evidence that vault placeholders survive into recorded MCP invocations while the real secret is substituted later.

The current seed bridge controller also documents one remaining implementation detail plainly: it still expects a concrete in-process tools provider to be wired in before that endpoint can expose a real catalog of tools through the bridge. That is an implementation note about the present seed, not a different governance model.

The important part is already visible in the codebase: external assistants are meant to arrive under the same controls, not around them.

The point of MCP here

MCP is useful because it gives a standard connector for outside assistants. But the protocol itself is not the product story.

The product story is sameness of control:

• the assistant arrives as an identity
• the host resolves the allowed surface
• sensitive actions stay gated
• secrets stay server-side
• every call lands on the same audit trail

That is why the CLI path matters. It is not a novelty connector bolted onto the side. It is one more way to reach the same governed surface.