{"slug": "when-hidden-reasoning-isn-t-hidden-the-openai-anthropic-google-encrypted-trace", "title": "When \"Hidden\" Reasoning Isn't Hidden: The OpenAI/Anthropic/Google Encrypted Trace Replay Bug", "summary": "Researchers disclosed in August 2026 that encrypted reasoning objects across OpenAI, Anthropic, and Google APIs could be replayed outside their original context, allowing secrets to be extracted across users and into weaker models. The flaw, which went undetected by standard security tooling, exposed API keys, passwords, and access tokens from reasoning traces that never appeared in visible outputs. The incident highlights a gap in the threat model for encrypted reasoning, as vendors' encryption was not strictly bound to session, user, and model identity.", "body_md": "Researchers disclosed in August 2026 that encrypted reasoning objects across OpenAI, Anthropic, and Google APIs could be replayed outside their original context. Not just replayed by the same user in a later session. Replayed across users. Replayed into weaker models that had no business decoding a stronger model's internal reasoning at all.\n\nThe result: hundreds of real secrets pulled out of reasoning traces that never once appeared in the visible model output. API keys, passwords, access tokens, sitting in \"encrypted\" blocks that were supposedly opaque by design. Nobody's dashboard flagged it. Nobody's log review caught it. Because the entire point of encrypted reasoning is that you're not supposed to be able to read it, so nobody was looking.\n\nThat's the part that should bother you more than the exploit mechanics. This wasn't a leaked plaintext log. This was content deliberately marked \"you can't see this\" that turned out to be readable by the wrong party, and the secrets inside were never meant to leave the model's internal scratchpad in the first place.\n\nModern reasoning models (o1-style, extended thinking, whatever your vendor calls it) generate an internal chain-of-thought before producing the final answer. Vendors encrypt or otherwise obscure that intermediate reasoning so customers can't scrape competitor training signal out of it. Fair enough, that's a legitimate IP concern.\n\nBut encryption without strict binding to session, user, and model identity is just obfuscation with extra steps. If the encrypted blob can be replayed, decoded, or handed to a different (weaker, presumably less-restricted) model that will happily decode and echo it back, you've built a side channel. The stronger model did the \"sensitive\" reasoning. The weaker model becomes the unwitting decryption oracle.\n\nAnd here's the part specific to this incident: agentic workflows routinely pull data into reasoning contexts that never gets surfaced in the final answer. A model reasoning about \"should I use this API key from the config file to make this call\" doesn't need to print the key in its response, it just needs the key present in its reasoning trace to complete the task. If that trace leaks, so does the key, and nobody sees it happen because the visible transcript looks completely clean.\n\nSame mechanism enables invisible prompt injection. If an attacker can get content into a reasoning block that later gets replayed or decoded by another model instance, they've smuggled instructions into a channel nobody is inspecting, because the entire security model was \"you can't read this, so we don't scan it.\"\n\nStandard LLM security tooling watches the visible input/output stream: user prompt in, model response out. That's the whole surface most proxies, guardrail libraries, and DLP tools are built to inspect.\n\nEncrypted reasoning traces sit outside that surface by design. They're not \"output\" in the conventional sense (they're marked internal/opaque), they're not logged the same way, and vendors explicitly discourage trying to parse them. So even a well-instrumented pipeline that scans every user message and every assistant response never touches the reasoning block, because it was never designed to be touched. That's not a gap in implementation, it's a gap in the threat model. Nobody wrote a rule for \"what if the thing labeled unreadable gets read by someone else.\"\n\nTraditional secret-scanning also assumes secrets show up in text that eventually reaches a human or a log line someone reviews. A key that only ever exists inside a reasoning trace, gets replayed cross-session, and gets decoded by a different model instance, never crosses any of the checkpoints a typical secrets-scanning pipeline watches.\n\nI want to be precise about scope, because this incident is about a provider-side API flaw in how reasoning traces are encrypted and bound to sessions. Sentinel doesn't sit inside OpenAI's or Anthropic's reasoning encryption pipeline, nobody's middleware does. What Sentinel *does* sit on is the boundary where content, including anything decoded out of a replayed reasoning trace, gets pulled into a tool result or a response payload that flows through the agentic proxy or the direct scrub endpoint.\n\nThat matters here specifically because of how the leak actually manifested: secrets embedded in reasoning traces that never appeared in visible output, until something (a replay, a weaker model echoing decoded content) causes that trace content to surface somewhere Sentinel can see it — a tool result, a log payload getting scrubbed before storage, content getting passed to another model call in an agentic chain.\n\nThat's Layer 4 territory: secret and credential detection. It's a dedicated detector that runs independently of the threat-scoring pipeline, which is exactly the right shape for this incident. The reasoning trace's *threat score* might be totally unremarkable (it's not a jailbreak attempt, it's not an authority hijack), but the content still contains a live API key or access token. A pipeline that only scores for adversarial intent would wave this straight through. Layer 4 doesn't care about intent, it pattern-matches on the credential itself.\n\nSpecifically, if a replayed or decoded reasoning trace ever gets ingested through `/v1/scrub`\n\nor shows up in a tool result on the agentic proxy, Layer 4 would catch:\n\n`ANTHROPIC_API_KEY=...`\n\n, `STRIPE_SECRET=...`\n\n) via keyword matching on the variable name, regardless of what's around it`sk-ant-...`\n\n, `sk-proj-...`\n\n, `ghp_...`\n\n, `AKIA...`\n\n, `xoxb-...`\n\n, and Bearer tokens in Authorization headersNone of that detection depends on understanding the *intent* of the surrounding text. It doesn't matter if the secret is sitting in a reasoning block, a config dump, or a casual aside. If it matches the pattern, it gets flagged or redacted depending on `secret_filter_level`\n\n.\n\nThe invisible-prompt-injection half of this incident (instructions smuggled into opaque reasoning blocks) is a Layer 2/3 problem instead: fast-path regex for authority hijacks and persona shifts, deep-path vector similarity for anything that doesn't match a known pattern but scores close to one semantically. If decoded reasoning content ever lands in a tool result flowing through the agentic proxy, it gets scanned like any other untrusted content, same threat pipeline, no special-casing because it happened to originate from a reasoning trace instead of a normal tool response.\n\nTo be clear: this is a hypothetical payload showing what Sentinel would do if decoded reasoning-trace content (containing a leaked credential) got routed through `/v1/scrub`\n\n. The incident itself doesn't specify Sentinel involvement, this is illustrative of the detection mechanism only.\n\n``` python\nimport httpx\n\n# Hypothetical: content decoded from a replayed reasoning trace,\n# now being logged or passed to another model call\ndecoded_reasoning_fragment = \"\"\"\nInternal reasoning: to complete this task I'll need to call the\nbilling API. ANTHROPIC_API_KEY=sk-ant-api03-xxxxxxxxxxxxxxxxxxxx\nAlso noting the user's Stripe key from config: sk_live_51Hxxxxxxxxxx\n\"\"\"\n\nresponse = httpx.post(\n    \"https://api.sentinelaifirewall.com/v1/scrub\",\n    json={\"content\": decoded_reasoning_fragment, \"tier\": \"strict\"},\n    headers={\"X-Sentinel-Key\": \"sk_live_...\"},\n)\nresult = response.json()\nprint(result[\"security\"][\"action_taken\"])   # \"clean\" - not adversarial intent\nprint(result[\"security\"][\"secret_hits\"])    # 2\nprint(result[\"security\"][\"secret_types\"])   # [\"env_secret\", \"anthropic_key\"]\nprint(result[\"safe_payload\"])\n```\n\nIllustrative response:\n\n```\n{\n  \"request_id\": \"a1b2c3...\",\n  \"security\": {\n    \"action_taken\": \"clean\",\n    \"threat_score\": 0.02,\n    \"secret_hits\": 2,\n    \"secret_types\": [\"env_secret\", \"anthropic_key\"]\n  },\n  \"safe_payload\": \"Internal reasoning: to complete this task I'll need to call the billing API. ANTHROPIC_API_KEY=[ENV_SECRET]\\nAlso noting the user's Stripe key from config: [ANTHROPIC_KEY]\\n\"\n}\n```\n\nNotice `action_taken`\n\nis `clean`\n\n. The threat scorer correctly sees nothing adversarial here, no injection attempt, no jailbreak language. But `secret_hits`\n\nis 2 and `safe_payload`\n\nhas both credentials redacted anyway, because Layer 4 runs independently of threat scoring. That independence is the whole point: a credential leak doesn't need adversarial intent to be dangerous, it just needs to exist in content that reaches a log, a prompt, or a downstream model call.\n\nIf you're building agentic pipelines that pass reasoning traces, tool outputs, or any intermediate model content between sessions, models, or storage layers, stop assuming \"encrypted\" or \"opaque\" means \"safe to skip scanning.\" Scan it at the boundary where it becomes readable text again, regardless of what it's labeled upstream. Secret detection needs to run on that content independent of whether your threat classifier thinks the content looks adversarial, because a leaked API key doesn't announce itself with injection syntax. It just sits there, quietly, until something replays it back into view.\n\nCheck out [Sentinel-Proxy](https://sentinelaifirewall.com) if you want that boundary scanning wired into your agentic stack without building your own credential-detection layer from scratch.", "url": "https://wpnews.pro/news/when-hidden-reasoning-isn-t-hidden-the-openai-anthropic-google-encrypted-trace", "canonical_source": "https://dev.to/coridev/when-hidden-reasoning-isnt-hidden-the-openaianthropicgoogle-encrypted-trace-replay-bug-2a5j", "published_at": "2026-08-16 13:04:27+00:00", "updated_at": "2026-08-16 13:12:17.929762+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy", "ai-infrastructure", "ai-agents"], "entities": ["OpenAI", "Anthropic", "Google", "Sentinel"], "alternates": {"html": "https://wpnews.pro/news/when-hidden-reasoning-isn-t-hidden-the-openai-anthropic-google-encrypted-trace", "markdown": "https://wpnews.pro/news/when-hidden-reasoning-isn-t-hidden-the-openai-anthropic-google-encrypted-trace.md", "text": "https://wpnews.pro/news/when-hidden-reasoning-isn-t-hidden-the-openai-anthropic-google-encrypted-trace.txt", "jsonld": "https://wpnews.pro/news/when-hidden-reasoning-isn-t-hidden-the-openai-anthropic-google-encrypted-trace.jsonld"}}