Cursor extension access control flaw exposes AI developer keys

At a glance

What this is: Cursor’s local credential storage lets any installed extension read API keys and session tokens, exposing developers to silent credential theft.

Why it matters: For IAM, PAM, and NHI teams, this is a reminder that developer tooling can become an identity-control weak point when secrets are not isolated, encrypted, and bounded by enforceable access policy.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 28% of secrets incidents now originate outside code repositories in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read LayerX Security's analysis of Cursor extension credential exposure

Context

Cursor’s issue is straightforward: if an extension can read the same local store as the application, then the application has not actually separated sensitive identity material from untrusted code. That matters because API keys and session tokens are not generic data, they are live credentials that can be replayed, abused, and chained into broader access across connected services. In AI development environments, the identity control plane often lives inside the workstation, not the backend.

For IAM and NHI programmes, this is a trust-boundary failure, not just a software bug. The practical problem is that the developer workstation now holds credentials for third-party AI services, source control, and internal tools, while extension ecosystems can execute code with enough reach to exfiltrate them. That pattern turns local extensibility into a credential-governance issue, especially where service accounts, API keys, and session tokens have broad standing privilege.

Key questions

Q: What breaks when a development tool stores API keys outside protected storage?

A: The security boundary breaks first. If extensions or plugins can read the same local store as the application, any malicious or compromised add-on can harvest bearer credentials and reuse them elsewhere. That turns a workstation utility into an identity exposure point, especially when the keys grant access to AI services, source control, or internal systems.

Q: Why do local extension ecosystems increase NHI risk for AI developer tools?

A: Because extensions often run with broad access to the host application’s files, data stores, and network paths. If those permissions are not strictly separated from credential storage, the extension can become a covert exfiltration channel. In NHI terms, the problem is not the extension label, it is the authority the runtime gives it.

Q: How can security teams judge whether developer secret storage is actually safe?

A: They should test whether untrusted add-ons can directly read credential stores, whether secrets are encrypted at rest, and whether access is mediated by a system vault or equivalent boundary. If a plugin can query keys from a local database, the storage model is not safe enough for live credentials.

Q: Who is accountable when a tool vendor leaves credential exposure unpatched?

A: The vendor remains accountable for the software control failure, but the deploying organisation still owns the risk acceptance decision. Security teams should document the exposure, restrict affected tooling, and decide whether the business case justifies continued use while the flaw remains open. That is the point where governance meets operational tolerance.

Technical breakdown

Local secret storage and extension trust boundaries

Cursor stores credentials in a local SQLite database rather than in a protected credential vault such as an OS keychain. That means the application depends on a trust boundary it does not enforce between the core app and installed extensions. When an extension can open the same database file, it inherits visibility into tokens and keys that should have been isolated from untrusted code. The failure is architectural, not cosmetic: sensitive identity material sits in a readable store on the same endpoint as arbitrary extension code.

Practical implication: treat local credential storage as a privileged asset and verify that extensions cannot read it directly.

API keys and session tokens as replayable identity artifacts

API keys and session tokens are not just configuration values. They are bearer credentials that can usually be replayed by whoever obtains them, often with the same authority the original user or integration had. In an AI development tool, those credentials may unlock upstream models, developer services, or adjacent SaaS integrations. If the token is valid, the attacker does not need to defeat authentication again, because the stolen credential becomes the authentication event.

Practical implication: classify developer-facing AI credentials as live identity assets and scope them as tightly as possible.

Silent exfiltration from a trusted extension environment

The report’s proof of concept shows that once a malicious extension is installed, it can query local credential data and send it off-host without user interaction or visible warning. That is a classic trust-extension problem: the platform assumes extension behaviour is benign, but the runtime gives the extension enough access to turn local read capability into remote credential theft. Because the action occurs after installation and inside the approved extension surface, traditional user prompts do not interrupt the chain.

Practical implication: control extension provenance and monitor for unexpected outbound traffic from developer tooling.

Threat narrative

Attacker objective: The attacker aims to steal live developer credentials and reuse them to access connected AI and development services as the victim.

1. Entry occurs when a developer installs a benign-looking Cursor extension from a marketplace or repository, giving the attacker code execution inside the extension environment.
2. Credential access follows because the extension can directly read the local SQLite database that stores API keys and session tokens without any separate permission gate.
3. Impact occurs when the attacker exfiltrates the stolen credentials and reuses them for backend access, third-party service abuse, and user impersonation.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Protected local storage is the broken premise here: the platform assumed sensitive credentials would be separated from untrusted extension code, but the database design erased that boundary. Once API keys and session tokens are stored where any extension can read them, the control is no longer access control but hope. Practitioners should recognise this as a local trust-boundary failure in developer identity tooling, not merely a product bug.

Cursor extension access creates identity blast radius across the AI stack: a stolen key in this environment is rarely limited to one application. The same credential can reach model providers, backend services, and connected integrations, so one local exposure can become multi-service abuse. That expands the governance problem from endpoint hygiene to non-human identity containment across the full developer workflow.

Standing credential exposure window: this vulnerability shows what happens when bearer credentials persist in a readable store long enough for any installed extension to harvest them. The issue is not that credentials exist, but that they are continuously exposed to code that should never see them. The implication is that bearer secrets in AI development environments are part of the attack surface, not just the configuration surface.

Secret storage without enforced extension isolation does not meet modern NHI governance expectations: OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework both point to access isolation, credential protection, and least privilege as baseline controls. Here, the absence is sharper than a missed setting. The environment treated local extensibility as compatible with secret custody, and that assumption breaks under any adversarial extension model.

Developer tooling is now an identity boundary, not just a productivity layer: organisations that allow broad AI coding tool adoption need to govern the credentials those tools touch as carefully as they govern production service accounts. The practical conclusion is that endpoint software, extension ecosystems, and secret handling are now one control plane for NHI risk.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that detection without revocation leaves live NHI exposure in place.
• For broader context, read Guide to the Secret Sprawl Challenge for the lifecycle controls needed when secrets move through developer tooling and AI workflows.

What this signals

Secret custody is becoming a platform governance issue, not just a vaulting issue: as AI development tools absorb more credentials, teams need to decide whether local extensibility is compatible with live bearer secrets. The answer is increasingly no unless extension isolation, encrypted storage, and strong provenance checks are enforced together. That is the practical boundary line for developer-facing NHI governance.

Cursor-style failures also show why extension ecosystems must be reviewed like third-party access paths. If a plugin can touch tokens, the organisation must govern that plugin with the same seriousness it applies to service account access. The control question is no longer whether the tool is productive, but whether it can expose identity material without a reviewable gate.

Identity blast radius: a single exposed API key can now reach multiple AI and SaaS services, which means one local mistake can become a cross-platform incident. In our view, that pushes teams toward shorter-lived credentials, tighter integration scoping, and explicit containment of developer tooling as part of the NHI programme.

For practitioners

• Map every AI developer tool that stores credentials locally Inventory which tools hold API keys, session tokens, and cached secrets on the endpoint, then classify those stores as high-value identity assets rather than application data. Prioritise tools that support third-party extensions or plugins because they widen the read surface for local credential theft.
• Separate extension code from secret custody Require protected storage for secrets, such as OS-backed credential managers or an encrypted secrets layer, and block direct database access from extension runtimes. If a tool cannot enforce that boundary, treat it as unsafe for credentials that grant upstream service access.
• Reduce the blast radius of developer API keys Replace broad, reusable bearer credentials with tightly scoped tokens, short lifetimes, and service-specific access where possible. Review whether third-party AI and development integrations still need the authority currently embedded in long-lived keys.
• Control extension provenance and runtime behaviour Limit allowed extension sources, review extension permissions against actual file and network access, and monitor outbound requests from developer tooling for unusual exfiltration patterns. The key question is whether an approved extension can reach identity material silently.

Key takeaways

• This case shows that local AI developer tooling can become an identity exposure point when extensions can read live credentials.
• The scale of impact is broader than the host application because stolen API keys and session tokens can be replayed across connected services.
• The control that would have changed the outcome is enforced separation between untrusted extensions and protected credential storage.

Key terms

• Local Credential Store: A local credential store is an on-device location where an application keeps API keys, session tokens, or other secrets. In secure designs, that store is isolated from untrusted code and protected by operating system controls or encryption. If extensions can read it directly, it is functioning as exposed identity material rather than safeguarded storage.
• Extension Trust Boundary: An extension trust boundary is the line that separates approved application behaviour from add-on code that should not see sensitive data. When that boundary is weak, a plugin can inherit access to files, tokens, and network paths that were never meant to be exposed. For AI tools, that boundary often determines whether the app can safely hold live secrets.
• Bearer Credential: A bearer credential is a secret that grants access to a service simply because the holder possesses it. API keys and many session tokens work this way, which makes them highly reusable if stolen. In identity governance, bearer credentials require strict storage, scoping, and lifecycle control because possession often equals authority.

Deepen your knowledge

AI developer tool credential exposure and extension isolation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around developer tooling and live API keys, it is worth exploring.

This post draws on content published by LayerX Security: Cursor extension access control flaw exposes AI developer keys. Read the original.