Claude extension secret encryption still leaves cross-plugin theft

At a glance

What this is: This is an analysis of Claude extension secret encryption and the finding that cross-extension blob copying still lets one plugin steal another plugin’s API keys.

Why it matters: It matters because identity and secrets governance cannot rely on encryption alone when every extension can still inherit access to every other extension’s credentials.

👉 Read CYATA's analysis of encrypted Claude extension secrets and cross-plugin theft

Context

Encrypted storage is not the same as identity isolation. In this case, secrets are no longer sitting in plaintext on disk, but the trust boundary between extensions has not changed, so a malicious or compromised plugin can still reach credentials intended for another plugin. That is a non-human identity governance problem, not just a storage problem.

For IAM and NHI teams, the relevant question is whether extension-level secrets are bound to a stable identity and a bounded permission scope, or whether any installed component can replay another component’s encrypted state. If the answer is the latter, encryption reduces casual exposure but leaves lateral secret theft intact.

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 do encrypted secrets still create risk in plugin ecosystems?

A: Encrypted secrets still create risk because the application, not the extension, may control decryption. If any installed plugin can cause the host to decrypt shared blobs, then the trust decision is made at runtime after installation, not at provisioning. That leaves no true per-plugin isolation and makes credential theft a platform behaviour, not just a malware issue.

Q: How do security teams know whether extension secret handling is actually isolated?

A: Test the replay path. A platform is not isolated if a secret created by one extension can be copied into another extension’s settings and still decrypt correctly. Also check whether decrypted values are exposed as environment variables or shared memory, because that reveals whether the runtime is enforcing actor boundaries or only encrypting files.

Q: Who is accountable when one plugin steals another plugin’s API keys?

A: Accountability sits with the platform owner and the extension governance process, not just the attacker. The control failure is allowing shared decryption rights across extensions, so the organisation must treat extension approval, secret scoping, and runtime containment as part of the same identity governance decision. OWASP Non-Human Identity Top 10 is a useful reference point for that review.

Technical breakdown

Why encrypted extension secrets can still be copied and reused

The vendor’s design uses OS-backed encryption, such as Keychain on macOS or DPAPI on Windows, to store sensitive values as encrypted blobs rather than plaintext. That protects the file at rest, but it does not bind the blob to the specific extension identity that created it. If another extension can copy the blob into its own settings and mark the field as sensitive, the host application will decrypt it on behalf of the attacker. The weak point is trust context, not cipher strength.

Practical implication: treat encrypted extension storage as obfuscation unless the decrypted secret is bound to an extension-specific identity and runtime boundary.

Extension-to-extension trust breaks the secrets perimeter

This pattern turns every installed extension into a potential secrets collector. The host application becomes the decryptor for any value it recognises as sensitive, which means the permission boundary is effectively the application itself rather than the individual plugin. In NHI terms, the credentials are not governed by least privilege at the actor level, because one actor can inherit another actor’s secret material without re-authentication, approval, or scoped access grant.

Practical implication: inventory which extensions can read or replay shared secret stores and remove any assumption that per-plugin encryption equals per-plugin isolation.

Why OS credential managers are not enough without application-level scoping

Keychain and DPAPI are strong storage primitives, but they do not solve application design flaws. They protect secrets from casual disclosure and local file inspection, yet they still rely on the application to decide who should be allowed to ask for decryption. If the app decrypts any blob flagged as sensitive, the control boundary has been pushed above the OS layer and into the extension runtime, where one compromised component can weaponise a normal decryption workflow.

Practical implication: require application-level secret scoping, not just OS-backed encryption, before treating an extension platform as safe for credential-bearing workflows.

Threat narrative

Attacker objective: Steal every accessible plugin credential from a shared extension environment and use them for downstream access or exfiltration.

1. Entry occurs when a rogue or compromised extension is installed into the Claude extension environment and gains access to local settings files containing encrypted secret blobs.
2. Escalation occurs when the attacker copies another extension’s encrypted blob into its own configuration and marks the field as sensitive, causing the host application to decrypt it for that extension.
3. Impact occurs when the attacker reads the resulting environment variables and exfiltrates API keys or other credentials from the victim extension.
4. The objective is to steal cross-extension API keys without needing direct access to the original secret store or the user’s plaintext credentials.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Encrypted-at-rest secrets do not equal governed non-human identities: The article shows that the secret is protected from disk inspection but not from cross-actor reuse. That is the difference between storage hardening and identity control, and it matters because NHI governance is about who can use a credential, not only how it is stored. Practitioners should read this as a trust-boundary failure, not a cryptography failure.

Extension ecosystems create identity blast radius when decryption is centralised: If the host application decrypts any blob flagged as sensitive, every extension inherits the same decryption path. That collapses the intended separation between creators and consumers of secrets, so a compromise in one plugin becomes a credential event for all plugins. The practical conclusion is that plugin platforms need identity scoping, not shared decrypt privileges.

Secret isolation must be bound to actor identity, not file format: A named concept here is cross-extension secret replay, where encrypted material is copied from one extension context into another and successfully decrypted. This is the governance gap the article exposes: the system treats secrets as portable ciphertext instead of actor-bound authority. Practitioners should assume any design that allows replay has already lost containment.

Least privilege fails when the platform, not the extension, holds the power to decrypt: Least privilege is usually defined at provisioning time, but this design lets the runtime decide who receives the secret. That makes the permission model reactive rather than bounded, and it can only be reasoned about after installation, not before. Security teams should treat any shared decryption path as standing privilege across the extension estate.

Operational trust in extension marketplaces now has an identity-security dimension: The question is no longer only whether an extension is malicious, but whether the platform lets one extension borrow another extension’s secret state. That shifts governance from package review to runtime containment, where secret handling, extension permissions, and local host trust all need to be assessed together. Practitioners should re-evaluate plugin approval criteria accordingly.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• Around 100,000 valid secrets were found in public Docker images, with ENV instructions alone accounting for 65% of all secret leaks in containers.
• The Secret Sprawl Challenge shows why teams should pair secret discovery with lifecycle control, not storage hardening alone, in Guide to the Secret Sprawl Challenge.

What this signals

Cross-extension secret replay: This is a useful name for the pattern where encrypted material is portable across plugin identities and therefore replayable at runtime. Once a platform decrypts any blob that is merely marked sensitive, the governance unit is no longer the individual extension, it is the host application’s shared trust boundary. That should push teams to reassess extension approval, runtime segmentation, and secret ownership together.

With 4.6% of all public GitHub repositories containing at least one hardcoded secret, secret exposure is already common enough that local plugin ecosystems should be assumed hostile by default. The next step for practitioners is to decide whether their current extension model creates actor-bound authority or just encrypted portability.

The operational signal is not whether secrets are encrypted on disk, but whether a different extension can reuse them without a new trust decision. If that test passes, the environment has no meaningful per-plugin containment, and the programme should be treated as a shared secrets domain rather than a collection of isolated identities.

For practitioners

• Inventory every extension with secret access Map which Claude extensions can read, copy, or request decryption of sensitive blobs. Remove any extension that does not have a specific business need for credential-bearing workflows, and treat broad secret visibility as a high-risk exception rather than a default setting.
• Separate credential-bearing workflows from general-purpose plugins Do not allow the same extension runtime to host both trusted automation and unrelated add-ons when secrets are in scope. Where possible, isolate workflows so a compromised extension cannot reuse another extension’s decrypted state or environment variables.
• Verify whether decrypted secrets are actor-bound Test whether a secret encrypted by one extension can be copied into another extension’s settings and still be decrypted. If that replay succeeds, the platform has shared trust rather than per-extension isolation, and the control gap is structural.
• Minimise credential blast radius before deployment Issue only the narrowest API keys or tokens needed for each plugin and rotate them if an extension has broad or overlapping access. Shared decryption paths make token scope the last meaningful containment layer when extension isolation is weak.

Key takeaways

• Encrypting secrets at rest does not solve extension-to-extension trust when the platform can decrypt for any plugin.
• The exposure is structural because shared decryption paths create cross-extension secret replay and widen the blast radius.
• Practitioners should test actor binding, reduce credential scope, and treat plugin approval as an identity governance control.

Key terms

• Cross-Extension Secret Replay: A failure mode where encrypted secret material from one extension can be copied into another extension and still be decrypted. The issue is not weak cryptography. It is the absence of actor binding, which lets a platform treat portable ciphertext as if it were authorised for every plugin context.
• Extension Identity Boundary: The practical separation between one plugin’s authority and another’s in a shared runtime. If the host application can decrypt secrets for any extension that marks them sensitive, the boundary is weak or absent, and the extension ecosystem behaves like one shared identity domain.
• Encrypted At Rest: A storage control that protects secrets while they sit on disk or in a file. It reduces casual disclosure, but it does not guarantee that only the original actor can request decryption, so it must be paired with runtime scoping and identity-aware access rules.
• Identity Blast Radius: The amount of damage one compromised identity can cause before containment. In extension ecosystems, shared decryption paths increase blast radius because a single malicious plugin can reach credentials intended for other plugins, turning one installation decision into many downstream exposures.

What's in the full article

CYATA's full blog post covers the operational detail this post intentionally leaves for the source:

• A step-by-step walkthrough of how encrypted blobs are copied from one extension config into another.
• The exact macOS and Windows decryption behaviour that lets the host application unwrap sensitive values.
• Concrete examples of how stolen API keys can be read from environment variables after restart.
• A practical comparison of what encryption at rest does and does not protect in extension ecosystems.

👉 CYATA's full post shows the copy and decrypt workflow, platform behaviour, and attack path in detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.