A research team decoded 315,320 thinking blocks from 6,708 public agent trajectories and recovered 704 distinct privacy artifacts, including 62 API keys and 33 passwords, from OpenAI, Anthropic, and Google's reasoning APIs. The attack vector? Encrypted reasoning objects that could be replayed across sessions and models, allowing weaker models to decode the internal reasoning of stronger ones.
If you're running AI integrations in production, here's how to lock down your implementation before your session logs become someone else's credential store.
The Problem: Why This Matters Now
The vulnerability exploits a design assumption: that encrypted reasoning blocks are safe to log and replay because they're opaque. They're not. Matthew Green's earlier research demonstrated that these blocks could be replayed across sessions. The recent disclosure proved they could also be decoded by weaker models in the same provider's ecosystem.
Your exposure isn't theoretical. If you're logging agent trajectories for debugging, sharing example workflows in documentation, or storing session data for compliance auditing, you may have already published encrypted reasoning blocks containing credentials, PII, or proprietary logic.
The attack doesn't require sophisticated tooling. It requires access to your logs and an API key for the same provider.
What You Need Before Starting
Before you implement controls:
Inventory your AI integrations
- List every service using OpenAI, Anthropic, or Google AI APIs.
- Document which ones use reasoning models (o1, Claude with extended thinking, Gemini 2.0 Flash Thinking).
- Identify where you log API responses, agent trajectories, or debugging output.
Audit your current exposure
- Search your public repositories for
"reasoning"or"thinking_blocks"in JSON logs. - Check documentation sites, example code, and training materials.
- Review your observability platform for stored API response bodies.
Verify access controls
- Confirm who can read your application logs.
- Document which third-party services receive full API responses.
- Check if your logging pipeline strips sensitive fields before storage.
Get buy-in for log retention changes
- Reasoning blocks can be large (10KB+ per request).
- If you're currently storing full responses, you'll need approval to change retention policies.
- Budget for increased log storage costs if you implement structured redaction instead of blanket deletion.
Step-by-Step Implementation
Step 1: Stop Logging Reasoning Blocks Immediately
For OpenAI (o1 models):
# Before: vulnerable logging
response = client.chat.completions.create(...)
logger.info(f"API response: {response.model_dump_json()}")
# After: strip reasoning before logging
response_dict = response.model_dump()
if 'choices' in response_dict:
for choice in response_dict['choices']:
if 'message' in choice and 'reasoning' in choice['message']:
choice['message']['reasoning'] = "[REDACTED]"
logger.info(f"API response: {json.dumps(response_dict)}")
For Anthropic (Claude with extended thinking):
# Strip thinking blocks from responses
response_dict = response.model_dump()
if 'content' in response_dict:
response_dict['content'] = [
block for block in response_dict['content']
if block.get('type') != 'thinking'
]
For Google (Gemini 2.0 Flash Thinking):
# Remove thoughts from response before logging
if hasattr(response, 'thoughts'):
delattr(response, 'thoughts')
Step 2: Implement Structured Logging with Field-Level Controls
Don't just delete reasoning blocks. Implement structured logging that preserves debugging utility while removing sensitive data:
# Create a logging schema that separates metadata from content
safe_log_entry = {
"timestamp": response.created,
"model": response.model,
"prompt_tokens": response.usage.prompt_tokens,
"completion_tokens": response.usage.completion_tokens,
"finish_reason": response.choices[0].finish_reason,
"final_output": response.choices[0].message.content,
# Explicitly omit: reasoning, thinking blocks, raw message objects
}
Configure your observability platform to enforce this schema. In Datadog, set up log pipeline processors:
- Create a remapper processor to extract safe fields.
- Add a category processor to tag AI API calls.
- Configure an exclusion filter to drop any log containing
reasoningorthinkingfields.
Step 3: Rotate Exposed Credentials
Search your logs for the pattern of exposed secrets:
# Search for common credential patterns in logged reasoning
grep -r "api_key\|password\|secret\|token" /var/log/ai-agent/ | \
grep -i "reasoning\|thinking"
If you find matches:
- Rotate the credentials immediately.
- Document which systems were affected.
- Review access logs for those credentials to identify potential unauthorized use.
Step 4: Implement Request-Level Sanitization
For applications that must log reasoning for compliance (e.g., SOC 2 Type II audit trails), implement sanitization before the reasoning reaches your logs:
import re
def sanitize_reasoning(reasoning_text):
"""Remove credentials and PII from reasoning blocks"""
patterns = {
'api_key': r'(?i)(api[_-]?key|apikey)[\s:=]+[\w-]{20,}',
'password': r'(?i)(password|passwd|pwd)[\s:=]+\S+',
'email': r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b',
'ip_address': r'\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b',
}
sanitized = reasoning_text
for pattern_name, pattern in patterns.items():
sanitized = re.sub(pattern, f'[REDACTED_{pattern_name.upper()}]', sanitized)
return sanitized
This isn't bulletproof. LLMs can encode credentials in unexpected formats, but it catches common patterns.
Step 5: Configure API-Level Controls
Enable provider-specific security controls where available:
OpenAI: Set store: false in your API requests to prevent OpenAI from storing your conversations for model improvement:
response = client.chat.completions.create(
model="o1-preview",
messages=messages,
store=False # Prevents storage in OpenAI's systems
)
Anthropic: Use the disable_prompt_caching parameter for sensitive workflows to prevent reasoning from being cached across requests.
Google: Configure Vertex AI's data residency controls to limit where reasoning data is processed and stored.
Validation: How to Verify It Works
Test 1: Log Inspection
Generate a test request with a known fake credential in the prompt. Verify your logs contain [REDACTED] instead of the credential.
Test 2: Replay Attack Simulation
If you have access to a weaker model in the same provider's ecosystem, attempt to replay a logged reasoning block. Your sanitized logs should not contain valid encrypted reasoning objects.
Test 3: Third-Party Service Audit
Review what your observability vendor stores. Export a sample of logs and verify reasoning blocks aren't present.
Test 4: Public Exposure Check
Search your organization's public GitHub repositories, documentation sites, and example code for:
# Search for leaked reasoning blocks in public repos
gh repo list YOUR_ORG --limit 1000 --json name | \
jq -r '.[].name' | \
xargs -I {} gh api repos/YOUR_ORG/{}/contents | \
jq -r '.[] | select(.name | endswith(".json") or endswith(".log"))'
Maintenance and Ongoing Tasks
Weekly: Review new AI integrations for reasoning API usage. Add them to your sanitization pipeline before they reach production.
Monthly: Audit log retention policies. Verify old logs with reasoning blocks have been purged according to your retention schedule.
Quarterly: Re-run credential pattern searches on your log archives. LLMs evolve in how they represent sensitive data in reasoning.
After each provider API update: Test that your sanitization logic still catches reasoning blocks. Providers may change field names or introduce new reasoning formats.
When onboarding new team members: Add AI API logging to your secure coding training. Developers need to understand that reasoning blocks are not safe to log, share, or commit.
This vulnerability won't be the last design flaw in AI reasoning systems. Build your logging and observability infrastructure to assume reasoning blocks are hostile, because once they're in your logs, you've lost control of who can decode them.
