Cursor extension access control flaw exposes AI developer keys

At a glance

What this is: This is a reported access control flaw in Cursor where extensions can read locally stored API keys and session tokens from an unsecured SQLite database.

Why it matters: It matters because IAM and security teams need to treat AI developer tools and their extension ecosystems as credential-bearing environments, not just productivity software.

Context

Cursor's problem is not just storage, it is trust boundary design. When developer tools keep API keys and session tokens in a local database without enforcing separation between the host application and extensions, any installed add-on can become a credential reader.

For identity and access management teams, this is a machine-identity exposure pattern inside a developer workstation context. API keys, session tokens, and third-party AI credentials become reachable through local extension execution rather than through an explicit access path.

LayerX Security says Cursor knew about the issue but had not fixed it at the time of reporting. That makes the flaw a governance problem as much as a technical one, because the control failure sits at the boundary between application design, local privilege, and secret handling.

Key questions

Q: What breaks when AI developer tools store API keys where extensions can read them?

A: The main failure is that local extension code can bypass the intended trust boundary and read secrets as plain application data. That turns the extension ecosystem into a credential exposure path, because the tool no longer separates untrusted add-ons from sensitive state. Once the key is readable locally, the attack becomes quiet and difficult to detect.

Q: Why do compromised developer tools create outsized risk for application secrets and API keys?

A: Compromised developer tools sit close to the systems that issue, store, or deploy secrets. If an attacker reaches that layer, they may obtain tokens, API keys, and environment variables that unlock additional services. That turns one breach into many, because stolen credentials can be reused, chained, or sold, while trusted automation spreads the impact quickly.

Q: How can security teams tell whether a developer tool is mishandling secrets?

A: Look for credentials stored in local files, databases, or caches that any plugin or extension can access without a separate privilege check. A tool that cannot demonstrate isolation between extensibility features and secret storage is already operating with an exposed trust boundary. That is a design issue, not just an implementation bug.

Q: Should organisations keep AI service credentials inside extensible developer apps?

A: Only when the app can prove strong isolation between extensions and secret material. If an extension can read the same database that holds API keys or tokens, the safer choice is to move those credentials into protected storage or a brokered secret flow. Otherwise the local client becomes part of the attack surface.

Technical breakdown

Why local secret storage breaks extension trust boundaries

Cursor stores credentials in a local SQLite database rather than in protected storage such as a system keychain. That matters because extensions with local read access can query the file directly, bypassing any application-level permission model. The core flaw is not that extensions exist, but that the application fails to isolate sensitive state from code running in the same trusted client context. Once secrets sit beside extensible code, the database becomes a credential source, not a private store.

Practical implication: treat local secret stores in extensible developer tools as part of the attack surface, not as safe internal storage.

How a benign extension becomes a credential exfiltration path

A malicious or compromised extension only needs ordinary extension execution to reach the database, extract API keys and session tokens, and send them out with a simple network request. No special permission prompt or interactive approval is required after installation. That makes the attack chain quiet and scalable, because the compromise happens through trusted local code rather than through obvious malware behaviour. The risk grows when the stolen keys unlock third-party AI services and downstream developer tooling.

Practical implication: review extension trust models as credential access controls, not just marketplace hygiene.

Why API key exposure in AI developer tools has broad blast radius

API keys in developer tooling often govern access to LLM providers, backend services, and automation workflows. Once exposed, the attacker can impersonate the user, consume billed services, and reach data that sits behind those integrations. This is a classic non-human identity problem because the credential itself is the actor, and its permissions may extend well beyond the local application. The blast radius is therefore defined by downstream entitlements, not by Cursor alone.

Practical implication: inventory which third-party services are reachable through developer-tool credentials and limit each key's scope aggressively.

Threat narrative

Attacker objective: The attacker wants usable developer credentials that can be replayed for data access, impersonation, and financial abuse across connected AI services.

1. Entry occurs when a developer installs a seemingly benign Cursor extension from a marketplace or repository.
2. Credential access follows immediately because the extension can read the local SQLite database that stores API keys and session tokens.
3. Exfiltration then occurs silently when the extension sends the extracted credentials to an attacker-controlled server.
4. Impact comes from account takeover, billed API abuse, and access to third-party AI services and associated data.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

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

Extension-readable secret stores create trust boundaries that extension ecosystems cannot safely assume away: When a local application stores API keys and session tokens in a database that any extension can read, the extension model itself becomes the control failure. The issue is not merely insecure storage, but the absence of an enforceable separation between user intent and code execution inside the same client. Practitioners should treat extensibility as a privilege boundary, not a convenience feature.

API keys in AI developer tools function as machine identities with unusually wide blast radius: Once those credentials can be read locally, their scope is no longer governed by the host application's UI or permission prompts. The real entitlement set lives in the connected services, where billing, data access, and automation permissions often exceed what the local tool can safely mediate. That makes downstream scope management the decisive control variable.

Protected storage assumptions fail when sensitive state is colocated with third-party code: The assumption that local application data is private was designed for software where extensions cannot directly inspect credential stores. That assumption fails when extensions can query the same database that holds active secrets. The implication is that developers must rethink where secrets live, because local persistence no longer implies local confidentiality.

Cursor's issue exposes a broader identity governance gap in AI development environments: AI tooling increasingly sits between human users and non-human identities such as API keys, tokens, and service accounts. When the tool does not enforce isolation, those identities become transferable through local code execution rather than through governed delegation. That is a lifecycle and entitlement problem, not just an application bug.

Secret handling for extensible AI tools now belongs in the same governance conversation as NHI offboarding and rotation: If a key can be captured by any extension, then rotation alone does not address the exposure window created at installation time. The control question becomes which credentials should never be stored where untrusted extension code can enumerate them. Practitioners need to reclassify local developer secrets as governed non-human identities, not disposable configuration.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: NHI Authentication Guide

What this signals

Extension-readable credential stores: AI developer tools that let third-party code inspect local secret databases create a governance problem that looks like software convenience but behaves like identity exposure. The relevant control question is whether the tool can keep non-human credentials out of any storage path reachable by extensions.

Teams should assume that API keys embedded in extensible clients belong in the same risk class as other high-value non-human identities. Once those credentials can be enumerated locally, rotation becomes necessary but insufficient, because exposure may already have occurred before the next governance cycle.

For practitioners

• Isolate extension access from credential stores Keep API keys and session tokens out of storage that extensions can reach directly. Use operating-system keychains or equivalent protected storage, and verify that extensions cannot open credential databases as plain local files.
• Inventory developer-tool credentials by downstream service Map every AI and developer service reachable through Cursor-issued keys, including LLM providers and internal APIs. Record scope, billing impact, and data access so compromise analysis is based on entitlement rather than tool name.
• Reduce key scope before installing extensions Prefer narrowly scoped tokens for developer workflows and separate them from credentials that can reach production data or high-value automation. The smaller the entitlement, the lower the blast radius if an extension reads the local store.
• Review extension trust as an access decision Treat every installed extension as code that may inspect local application state. Approve only extensions whose data access is compatible with the secrets stored on that workstation, and remove those that do not need local credential visibility.
• Move sensitive AI credentials out of extensible clients Where possible, keep high-value API keys in centralized secret management or brokered access flows instead of developer tools that permit third-party extensions. That reduces the chance that a plugin can read secrets before policy is enforced.

Key takeaways

• AI developer tools can fail at the trust boundary itself when extensions are allowed to read local credential stores.
• The compromise path is especially dangerous because it can expose API keys and session tokens without user interaction after installation.
• Protective storage, extension isolation, and reduced credential scope are the controls that matter most when non-human identities live inside extensible clients.

Key terms

• Expanded Trust Boundary: A broader set of inputs, contexts, and downstream actions that can influence a system’s behaviour. AI systems often create this boundary because unstructured language and external context can affect decisions in ways conventional APIs do not.
• Protected Storage: A storage mechanism that encrypts or otherwise restricts access to secrets such as API keys and session tokens. For AI developer tools, protected storage should prevent ordinary extensions or local files from reading credentials as plain data.
• Credential exfiltration: Credential exfiltration is the theft of usable authentication material such as tokens, keys, or certificates. In NHI environments, the stolen item is often already valid and can be replayed immediately. That is why detection must be paired with revocation and entitlement review rather than relying on alerts alone.
• Machine identity blast radius: The amount of data, systems, and workflows an attacker can reach after compromising a non-human identity. In Salesforce, broad object permissions and connected services can turn one token into access across CRM records, collaboration tools, and adjacent SaaS applications.

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.