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.
At a glance
What this is: This analysis shows that Claude’s encrypted .dxt secret storage still lets one extension copy and decrypt another extension’s secrets.
Why it matters: IAM and NHI teams should treat encryption at rest as incomplete when the execution boundary is the extension runtime, because isolation, ownership, and offboarding controls still determine who can reach credentials.
Context
Claude extensions can now mark secrets as sensitive and store them as encrypted blobs, but the security boundary did not move with the encryption. The core issue is not whether the value is encrypted on disk, but whether one extension can access another extension’s secret material once Claude decrypts it for runtime use.
For identity programmes, this is an NHI governance problem disguised as an application hardening improvement. If multiple extensions share the same decryption path and runtime trust domain, then secret protection depends on extension isolation, not on encryption alone.
The article argues that the control gap is cross-plugin trust, and that remains typical whenever secrets are shared across loosely isolated extension ecosystems.
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. If one extension can replay another extension’s encrypted blob and trigger decryption, encryption at rest no longer limits access to the originating actor. The result is shared privilege across the extension runtime, which turns a single compromise into a multi-plugin credential event.
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. If the host application decrypts any sensitive value for any extension, then OS credential stores only reduce disk exposure. They do not stop another extension from replaying or consuming the same material.
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. The goal is to make copied secrets useless outside their intended extension context.
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.
Technical breakdown
How encrypted extension secrets can still be stolen
The article describes a storage model where sensitive extension values are written as encrypted blobs rather than plaintext. That protects secrets at rest, but the decrypted value still has to exist somewhere at runtime so the extension can use it. If the host application reads any blob marked sensitive and passes it into the process environment, another extension that can reach those files may reuse the same decryption path. The security failure is not weak cryptography, but shared decryption authority across extensions that were never bound to separate trust domains.
Practical implication: Treat encrypted storage as insufficient unless each extension has its own decryption boundary and secret ownership is enforced end to end.
Why cross-plugin secret reuse breaks the trust model
The key weakness is secret portability. If one plugin can copy another plugin’s encrypted blob, update its own manifest, and then trigger decryption through the same host runtime, the encryption layer no longer expresses identity. The blob remains secret-shaped, but not issuer-bound or consumer-bound. In identity terms, this is a failure of secret provenance and runtime isolation. The extension that created the secret and the extension that consumes it are not distinguished at access time, so any plugin able to observe the storage path can become a reader.
Practical implication: Map which runtime components can read, replay, or relabel secret blobs, then remove any shared decryption path between extensions.
What OS key stores do and do not protect
Keychain on macOS and DPAPI on Windows protect secrets by tying them to the operating system user context, but that is not the same as binding them to a single extension. The article shows that OS-backed encryption can still support exfiltration when the application itself acts as a broad decryptor for any sensitive value it finds. That means the protection scope is the user session, not the plugin. For NHI governance, this is the difference between confidentiality of storage and isolation of execution. The latter is what matters when multiple extensions compete for the same credentials.
Practical implication: Review whether OS credential managers are being used as storage controls only, or mistakenly relied on as extension isolation controls.
Threat narrative
Attacker objective: Steal other extensions’ API keys and reuse them outside the original plugin trust boundary.
- Entry occurs when a malicious or over-privileged extension gains access to Claude extension settings files containing encrypted secret blobs.
- Credential access follows when the extension copies another plugin’s encrypted values and relabels them as sensitive in its own manifest.
- Escalation happens when Claude decrypts the copied blobs and passes the recovered secrets into the attacker-controlled runtime environment.
- Impact is theft of API keys and other credentials across plugins, with exfiltration to an external endpoint.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Secret provenance is the missing control concept here: A blob that can be copied, relabelled, and decrypted by another extension is not meaningfully tied to its original identity. This is a structural failure of ownership, not a simple confidentiality lapse. For practitioners, the important shift is to treat secrets as governed assets with explicit issuer and consumer boundaries.
Cross-plugin secret theft is a named governance gap, not an edge case: Any extension platform that centralises decryption for convenience creates a shared failure domain. Once one plugin can replay another plugin’s encrypted material, every credential in the environment inherits the same trust assumptions. The practitioner conclusion is that extension ecosystems need isolation controls that survive runtime access, not just storage encryption.
OWASP-NHI and zero trust both apply, but at different layers: OWASP-NHI captures the credential governance failure, while zero trust captures the missing assumption that runtime components should not inherit mutual trust by default. The article’s lesson is that encrypted storage is compatible with a broken trust model. The implication is to align identity governance with process separation, not only with encryption state.
Credential isolation must be treated as a lifecycle property: If any extension can ingest any other extension’s secret artifact, offboarding, rotation, and revocation lose their intended scope. The governance failure is not simply that secrets exist, but that they are reusable across identities that were never meant to share them. Practitioners should view this as a lifecycle and trust-boundary issue, not a pure storage problem.
From our research library:
- 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.
- Read next: API Key Management Guide
What this signals
Secret trust has moved from storage to runtime: The operational risk is no longer limited to plaintext files, because encrypted blobs can still be replayed if the platform decrypts them for any plugin that asks. That makes secret ownership and extension isolation the real governance controls, not encryption alone.
A compromised or malicious extension can turn a shared runtime into a credential collector, which is why plugin ecosystems need the same separation discipline that NHI teams apply to service accounts and shared API keys. If the runtime can decrypt on behalf of any extension, revocation and scoping lose their precision.
For practitioners
- Audit cross-extension secret reachability Map which Claude extensions can read settings files, copy encrypted blobs, and trigger decryption in the shared runtime. Identify any path where one plugin can consume another plugin’s credential material.
- 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. Shared host-level decryption should be treated as a design defect, not a convenience.
- 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.
- Remove unneeded extensions from the trust set Uninstall extensions that are not actively required, because every extra plugin increases the number of code paths that can observe or replay secret blobs.
- Test runtime isolation, not just encryption Verify whether an extension can copy another extension’s sensitive blob, relabel it, and still receive plaintext after restart. If that works, the platform is encrypting storage but not enforcing isolation.
Key takeaways
- Encrypted .dxt storage reduces disk exposure, but it does not prevent one extension from stealing another extension’s credentials.
- The practical failure is shared runtime trust, where copied secret blobs can still be decrypted and reused across plugins.
- Teams should govern plugin credentials as isolated identities, with small scopes, separate namespaces, and fewer extensions in the trust set.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Encrypted blobs are still leaked across plugins in this article. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party extensions act as the vulnerable identity boundary in this ecosystem. | |
| NHI-05 — Overprivileged NHI | Extensions can access more credentials than their own task requires. | |
| Recommendation — Treat copied extension blobs as leaked secrets and revoke any credentials exposed through shared runtime access. Assess extension suppliers and isolate their credential access before allowing them into the plugin trust set. Reduce each extension’s credential scope to the minimum needed for its function. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This is fundamentally an authorization boundary problem between extensions and secrets. |
| Recommendation — Revalidate extension entitlements so secret access is limited to the correct runtime identity. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article concerns API key handling and credential lifecycle. |
| Recommendation — Apply authenticator management controls to limit and rotate extension API keys. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack pattern is credential theft followed by outbound exfiltration. |
| Recommendation — Track copy-and-decrypt behaviour as credential access and monitor for resulting exfiltration. | ||
Key terms
- Cross-Plugin Secret Theft: The reuse of one extension’s encrypted secret material by another extension in the same runtime. The secret may be protected at rest, but if the host can decrypt it for any plugin, the trust boundary is shared and the credential remains stealable.
- Secret Namespace: The logical boundary that determines which identity or component is allowed to read a given secret. In extension ecosystems, a namespace must bind both storage and runtime access, otherwise copied credentials can be replayed by unrelated plugins.
- Runtime Decryption Boundary: The point at which encrypted data becomes usable plaintext inside an application process. When that boundary is shared across multiple extensions, encryption no longer isolates identities, it only hides the value until any authorised path exposes it.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org