Topic starter
09/07/2026 3:30 pm
TL;DR: Anthropic’s new .dxt secret handling encrypts stored values with Keychain or DPAPI, but Cyata shows any extension can copy another extension’s encrypted blobs, decrypt them, and exfiltrate API keys across both macOS and Windows. Encryption at rest reduces exposure on disk, but it does not create trust isolation between plugins.
Editorial analysis by NHI Mgmt Group, based on content published by CYATA: “Whispering Secrets Loudly – Patch, Meet Bypass”.
Key questions
Q: What breaks when extension secrets can be copied between plugins?
A: The boundary between trusted and untrusted plugins breaks first, then the secret model itself.
Q: Why does OS-backed secret encryption still leave extension ecosystems exposed?
A: Because the operating system protects the user context, not the plugin boundary.
Q: How should teams reduce the risk of cross-plugin API key theft?
A: Use per-extension secret namespaces, limit each plugin to the smallest possible credential scope, and remove unnecessary extensions from the environment.
Practitioner guidance
- Audit cross-extension secret reachability Map which Claude extensions can read settings files, copy encrypted blobs, and trigger decryption in the shared runtime.
- Separate secret ownership by extension Require each extension to have its own credential namespace and decryption boundary so copied blobs cannot be reused by unrelated plugins.
- Reduce plugin credential blast radius Issue the smallest possible API keys for extensions and remove any broad tokens that would let a compromised plugin access multiple downstream services.
Bottom line: Encrypted .dxt storage reduces disk exposure, but it does not prevent one extension from stealing another extension’s credentials.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 3:51 pm
Encrypted storage without plugin isolation is only obscured secret sharing: The article shows that .dxt encryption changes where secrets sit, not who can reach them. That means the governance question is no longer whether a secret is plaintext on disk, but whether the extension ecosystem has separate trust domains for each credential. The implication is that runtime isolation, not encryption alone, now defines the control boundary.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between encryption at rest and extension isolation?
A: Encryption at rest protects the stored value from casual disclosure, while extension isolation prevents one plugin from reaching another plugin’s credentials in the first place. A system can do the first well and still fail the second completely, which is the problem this article exposes.
👉 Read our full editorial: Claude extension secret encryption still leaves cross-plugin theft