Cursor's Agent Push Raises the Access Control Stakes

Cursor pushed out a wave of changelog items this cycle, and the theme is the same across all of them: agents doing more, with more standing access to your tools. At the same time, the developer conversation on Hacker News is circling back to a boring but important question — who actually controls your data once an agent, or a third-party integration, can reach it.

TL;DR

• Cursor now ships an SDK, self-hosted cloud agents, always-on automations, and 30+ marketplace plugins into tools like Atlassian, Datadog, GitLab, and PlanetScale — cursor.com/changelog
• A 304-point Hacker News thread on moving from Supabase to Clerk to Better Auth shows founders are actively rethinking who owns auth as apps grow
• New tools like CipherStash Stack are showing up specifically to add data-level access control on top of Postgres-style backends
• None of this changes the core rule: a public Supabase anon key or Firebase web config is not a leak — broken or missing row-level security is

Cursor's agents can now touch more of your stack

The Cursor SDK lets developers build their own agents on the same runtime and models that power the editor. Paired with self-hosted cloud agents that keep code and tool execution inside your own network, and automations that run always-on based on triggers, Cursor is giving agents longer leashes and more independence.

The marketplace expansion matters too: more than 30 new plugins from Atlassian, Datadog, GitLab, Glean, Hugging Face, monday.com, and PlanetScale mean an agent inside Cursor can now read from, and write to, more of your actual production stack than it could a few months ago. Enterprise customers got matching controls — service accounts, billing groups, and tighter security settings — but solo founders and small teams building with the free or standard tiers don't automatically get that same governance layer unless they set it up.

More reach for an agent is not inherently dangerous. But it does mean the question "what can this thing actually access" is worth asking every time you connect a new plugin or turn on an automation.

The access-control conversation is catching up

A popular Hacker News post, "From Supabase to Clerk to Better Auth", drew 304 points and 240 comments — a sign that a lot of teams are actively re-evaluating who handles authentication as their vibe-coded app grows past the prototype stage. Separately, CipherStash Stack launched on Show HN as a dedicated data-level access control layer for TypeScript/JavaScript apps, and InsForge is pitching itself as an open-source backend host built specifically for coding agents.

The common thread: the tooling ecosystem is starting to treat access control as its own product category, not an afterthought bolted onto a database. That's a healthy sign, but it also means the responsibility hasn't gone away — it's just getting more options.

What this means for your app

If you're running Cursor with new plugins or automations turned on, check what scopes and credentials each one actually has. Don't grant a Datadog or GitLab plugin broader access than the task needs. If you're on Supabase or Firebase, the exposure that matters is never the public anon key or web config — those are meant to be client-visible. It's whether your row-level security policies or Firestore rules actually restrict who can read and write what. A public key with solid RLS is fine. A public key with permissive or missing RLS is the actual hole.

FAQ

Does connecting Cursor to Atlassian, Datadog, or GitLab expose my data?

Not by default. These are opt-in plugins that request specific scopes. The risk comes from granting broader permissions than the workflow needs, or forgetting the plugin is connected after you stop using it.

Is a Supabase anon key or Firebase web config a security leak?

No. Both are public by design and meant to ship in client-side code. The real risk is missing or misconfigured row-level security (Supabase) or open Firestore/Realtime Database rules (Firebase) behind that key.

Should I switch away from Supabase because of the Better Auth thread on Hacker News?

Not automatically. That discussion reflects one team's path as their needs grew. Switching auth providers is a real engineering decision — evaluate it against your own app's scale and requirements, not thread popularity.

The bottom line

Agents are getting more autonomy and more integrations, and that raises the stakes on how you scope their access. But the fundamentals haven't moved: public keys are not leaks, and the thing worth checking today is still your RLS policies and database rules, not whether your Supabase config is visible in the browser.