In a separate experiment within its MCP infrastructure research, OX Security granted Claude Code an Always-Allow permission and then presented a malicious MCP server with a prompt-injection opportunity. The landing page says subsequent privileged file access occurred without another user confirmation when using Haiku 3.5. The same attack did not succeed…
Inspect the ClaimsCase · DiggingBeagle record
A model-specific MCP test reused an earlier always-allow permission for file access
OX Security reported a controlled Claude Code test where an always-allow permission was reused after malicious MCP content appeared, with sharply different outcomes across tested models.
Scope
Controlled Claude Code permission-persistence test, specifically Haiku 3.5 compared with Opus 4.6 and Opus 4.7; no confirmed live victim.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade C
- AI role
- AGAINST AI
Basis and provenance
OX reports a controlled Always-Allow test with divergent Haiku and Opus outcomes, but only a gated summary is accessible. Full client configuration, transcript, denominator and independent reproduction are missing.
Assessed Oct 11, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-OX-ALLOW-HAIKU · CLM-OX-ALLOW-OPUS · OX Security: 15,465 MCP servers, 0 governance
At a glance
A grant that remains valid for later MCP interactions removes a fresh approval boundary when the server or its content changes. Short-lived, operation-scoped tool grants would require renewed authority for later high-risk file access. This mechanism is distinct from DNS-based MCP server takeover, and model-specific resistance in the Opus tests does not…
Read the implicationsFull transcript, filesystem scope, number of repeated trials and permission configuration. Whether the result reproduces after client or model updates. No evidence of production exploitation.
Limits and uncertaintyFull account
In a separate experiment within its MCP infrastructure research, OX Security granted Claude Code an Always-Allow permission and then presented a malicious MCP server with a prompt-injection opportunity. The landing page says subsequent privileged file access occurred without another user confirmation when using Haiku 3.5. The same attack did not succeed against the tested Opus 4.6 or 4.7 configurations. These are model-and-configuration-specific observations; neither a universal Claude Code exploit nor a production file-theft incident follows. The detailed transcripts, trial counts and complete setup are not available from the public landing page.
Mechanism and trust boundary
- 01
Persistent permission
User previously allowed tool access through Always-Allow.
Boundary: Human approval to future unreviewed tool actions
- 02
Malicious MCP content
Later untrusted MCP content influences an action that uses privileged file access without a new prompt in the Haiku test.
Boundary: Third-party tool content to pre-authorized filesystem capabilities
Claims & evidence
CLM-OX-ALLOW-OPUSThe same OX Security page says its tested attack did not succeed against Opus 4.6 or Opus 4.7.supported
Basis: reported finding
- supportsOX Security: 15,465 MCP servers, 0 governanceprimary disclosure
Key Findings, Trust That Outlives the Original Permission
CLM-OX-ALLOW-HAIKUOX Security reports that a prior Claude Code Always-Allow grant enabled later malicious MCP prompt injection to trigger privileged file access without another confirmation in its Haiku 3.5 test.supported
Basis: reported finding
- supportsOX Security: 15,465 MCP servers, 0 governanceprimary disclosure
Key Findings, Trust That Outlives the Original Permission
Implications
A grant that remains valid for later MCP interactions removes a fresh approval boundary when the server or its content changes. Short-lived, operation-scoped tool grants would require renewed authority for later high-risk file access. This mechanism is distinct from DNS-based MCP server takeover, and model-specific resistance in the Opus tests does not establish a permission-system fix.
Unknowns and contradictions
- Full transcript, filesystem scope, number of repeated trials and permission configuration.
- Whether the result reproduces after client or model updates.
- No evidence of production exploitation.
Sources and citation
Material revision history
- Oct 11, 2026 · Published version · first publication · revision 123