The Trust Boundary Moved. Your Agent's Outputs Are Now Hosting It.

The trust boundary moved. Once an agent acts through tools, the dangerous question is no longer only what the model said. It is what the tool output can cause next.

Bright Security's July 21 research on ANSI escape sequence injection in MCP servers makes the shift concrete. A terminal control code can be invisible to a person reading a rendered response while remaining present in the bytes a language model consumes. That is not a clever prompt. It is a representation problem at the tool boundary.

The practical implication for a TPM is uncomfortable and useful: model evaluation is necessary, but it is not the release gate. The release gate is whether the tool chain can inspect, sanitize, constrain, and replay the output before it becomes a file write, a credentialed request, a purchase, or a production change.

The number that matters

The number that matters is not a benchmark score. It is the number of side effects one tool response can reach before anyone can stop it. A response that can trigger one read-only lookup has a different risk profile from a response that can reach a write API, a shell, a deployment system, or a payment workflow. Your program should make that difference explicit.

The official MCP security guidance treats token audience, consent, redirect validation, scope, sandboxing, and logging as implementation controls. Docker's July 22 CISO panel describes the same operating pattern in three words: isolate, control, observe. The layer between tool response and side effect is where those controls have to meet.

The framework: TOOLBELT

TOOLBELT is an operating framework for reviewing an agent workflow. It is my synthesis, not an industry standard or a compliance certification.

T: Trust the source. Name the server, owner, repository, version, and capability set. A tool without provenance is not a neutral integration. It is an unowned dependency with runtime authority.

O: Output sanitation. Normalize the response before it reaches a model-consumable field or a human approval screen. Strip terminal control bytes and other concealment characters. Validate the schema. Preserve the raw response separately for forensics. Bright Security's research recommends exactly this boundary treatment for ANSI escape sequences and says external and stored text should be treated as untrusted when it can reach the model.

O: Origin scoping. Keep the provenance of the data attached to the data. Public web content, a user comment, a repository file, and a trusted internal record should not arrive as indistinguishable text. The model may read all four, but the policy engine needs to know which one can be allowed to propose an action.

L: Lateral escape segmentation. Enforce the tool allowlist outside the model. The MCP security guidance warns against token passthrough and calls for least privilege, scope minimization, and restrictions around local servers. If a response can persuade the agent to invoke a new tool, the runtime should still decide whether that invocation is permitted.

B: Blast-radius ceiling. Set a per-call budget for files changed, records touched, network destinations, data classes, and money moved. A sandbox is valuable, but it is not a complete boundary if a trusted component later executes, loads, or scans what the agent wrote. DevOps.com's report on Pillar research puts the point plainly: the blast radius includes everything the host later trusts.

E: Escalation rule. Define the exact conditions that require a human to see the tool output and the proposed action together. Crossing from read to write, public to private data, or reversible to irreversible work should be a policy event, not a model confidence threshold. The goal is not to put a person in every loop. It is to put a deterministic stop in the loops where a mistake is expensive.

T: Traceability. Store the tool identity, call arguments, raw response hash, sanitized response, policy decision, actor, and resulting side effect. If an incident review cannot reconstruct what the model saw and what the runtime permitted, the system was never observable enough to govern.

The acronym is less important than the ordering. A response must be understood before it is trusted, constrained before it is empowered, and recorded before it is forgotten.

Why model evaluation cannot carry this alone

A model evaluation asks whether an agent completes a task under a defined set of prompts, tools, and fixtures. That is valuable. It does not tell you whether a live tool will return a hidden control sequence, whether a stored note will resurface in a later session, or whether a file created in a sandbox will be consumed by a trusted process outside it.

Bright Security separates direct-fetch and stored ANSI injection and recommends mapping the actual source-to-sink path into model-consumable fields. That is a testing insight TPMs can turn into a release criterion: do not only test the model's answer. Test what each tool response becomes after it crosses the runtime.

The same logic applies to browser and coding agents. DevOps.com's July 22 reporting says researchers found paths where an agent remained inside its sandbox while a trusted component outside the sandbox acted on files or tools the agent had influenced. The problem is not a magical escape from one process. The problem is trust transitivity.

What governance looks like without freezing velocity

The answer is not a policy PDF that developers must remember while an agent is moving. It is enforcement at the runtime layer.

Docker describes an MCP Gateway that sits between agents and external tools so calls can be authenticated, authorized, and logged before they reach the external system. Whether you use that product, another gateway, or an internal service, the program requirement is the same: make the safe path easier than the shadow path.

Ship a default profile with read-only tools, bounded network egress, sanitized output, append-only traces, and a visible approval checkpoint for write actions. Let teams request exceptions with an owner, an expiry date, and a test that proves the exception is still needed. This is how a control becomes an operating mechanism instead of a quarterly reminder.

GitHub's July 22 comparison of Copilot and raw API access makes a related commercial point: raw model access and a connected coding workflow are different layers. GitHub lists retrieval, routing, retries, logs, security model, billing, and credentials as system decisions. That is exactly why tool-output trust belongs on a platform scorecard, not in a model bake-off footnote.

The 30-day acceptance test

A TPM can turn TOOLBELT into a release review without creating a new committee. Ask the owner to show one real trace for each of these cases: a clean read, a malformed response, an external document with hidden control bytes, a tool that requests broader scope, and a proposed write action that crosses the escalation rule.

For each trace, verify five things. The raw response is retained. The sanitized response is visibly different when it should be. The policy decision is deterministic. The side effect is bounded or stopped. The replay record lets another engineer reconstruct the decision without asking the original operator what happened.

If the team cannot produce those traces, the agent is not ready for a broader rollout. It may still be useful in a contained pilot. Call it a pilot, give it a narrow budget, and do not let a successful demo masquerade as production evidence.

What this does not solve

It does not make the model reliable. Output controls do not replace task evaluations, calibration, red teaming, or careful prompt and tool design. They catch a different class of failure.

It does not make every source trustworthy. Provenance and sanitization reduce concealment and ambiguity. They do not turn a malicious document into a safe instruction or prove that a vendor's implementation is correct.

It does not remove the need for ownership. A gateway without an accountable owner becomes another service nobody patches, audits, or decommissions. Assign the runtime, tool catalog, policy rules, and incident response to named teams.

The signal that matters most

The strongest signal is the convergence of security guidance, agent runtime design, and procurement language around the same missing layer. MCP guidance talks about consent, token audience, scope, and auditability. Docker talks about isolating, controlling, and observing tool calls. Bright's research shows how a tiny representation detail can bypass a human reviewer's view. GitHub describes the harness around the model as the part that makes a workflow real.

The TPM move is to make that layer visible. Add tool-output control to the launch checklist. Give it an owner. Put a blast-radius ceiling on every write path. Require one replayable trace before expanding access. The model can remain the source of useful suggestions. The runtime has to decide what is allowed to become real.

Send me one tool-output control your team already operates and one gap you are closing. DM me on LinkedIn (Doron Katz). I am collecting working patterns into a practical agent-governance playbook; three examples would let me publish the next version.