|
Secure AI and MCP with protocol-level access control (Sponsored)
 |
Securing AI usually requires hardcoding permissions into application code for every MCP server, or using static API tokens for all-or-nothing access (and hoping your LLM doesn’t drift from intended actions).
Teleport eliminates these problems with zero-code MCP integration that applies the same zero trust security principles you use for human engineers:
Least privilege access control that denies new tools by default
Just-in-time (JIT) access requests for high-risk tools
Logs for every action – with full audit and identity context
Zero trust agent access to MCP servers, databases, and Kubernetes clusters
No need to write authorization code, rewrite MCP servers, or limit agent work.
When an AI model handles a difficult question, it produces three separate pieces of text:
The first is the answer displayed on screen.
The second is a shorter block, usually labeled thinking or reasoning, that appears while the answer is being assembled.
The third is the model’s full reasoning process, which is never displayed.
The second piece of text is a summary of the third. It is generated separately and shown in place of the original reasoning process. The full reasoning runs longer. It also contains material that the summary leaves out. Most major providers withhold it. However, in place of the complete process, an encrypted version is shared with the client during the conversation.
In August 2026, a team at MATS Research, the ELLIS Institute Tübingen, and the Max Planck Institute for Intelligent Systems wanted to test whether the encrypted reasoning blocks that Anthropic, OpenAI, and Google hand back to clients actually keep that reasoning private. They showed that the blocks can be replayed into a cheaper model in the same family, which will then print the hidden reasoning in plaintext. In other words, the AI model’s thoughts are stolen, exposing information that should ideally be hidden.
In this article, we will cover what the researchers found out:
Reasoning traces, and how they differ from answers and summaries
Why providers withhold reasoning
The storage problem that creates, and the two ways to solve it
What the encrypted block contains, and what it authenticates
The three forms of compatibility that follow
The extraction method and its verification
The four attack vectors
Findings from a scan of published session logs
The proposed fixes, and the limit that remains
 |
Disclaimer: This post is based on publicly shared details from various sources. References at the end. Please comment if you notice any inaccuracies.
Reasoning Traces
Modern frontier models first generate an extended internal sequence of text before producing a visible answer. For example, if we ask a model to solve a hard mathematics question, the model may generate two thousand words of exploration, dead ends, and corrections, which ultimately helps it write a clean two hundred-word answer. This longer sequence of exploration is the reasoning trace, which is also known as the chain of thought.
The trace holds intermediate hypotheses that the model may have tried and abandoned. It contains the raw output of any tools that were called, the user’s data as the model processed it, and whatever contextual secrets were present in the session. Unsurprisingly, this trace is much denser and more revealing than the final polished output.
For example, if we ask a coding agent to remove hardcoded credentials from a code repository, the agent has to read those credentials to do the work. In other words, the credentials pass through the reasoning trace before any answer is produced.
Concealment Rationale
Why do the model providers hide these reasoning traces?
There are two separate motivations:
The first is commercial. A competitor can collect a large number of traces from a strong model to create training material for building a cheaper imitation of the strong model. This is because the final answer just provides the endpoint of a computation, whereas a trace provides the methodology behind the answer.
The second is safety-related. A model sometimes has to generate reasoning about a harmful topic to refuse. The filtering that turns a completed trace into a safe visible answer runs after the trace already exists. Publishing the trace skips that filter and lets that information be seen by the user.