Cursor's always-on coding agents are here. Are your teams ready?
The news
Cursor shipped a feature called Automations on Thursday. The short version: instead of a developer prompting an AI agent every time they need something done, Automations lets you define triggers (a new commit, a Slack message, a PagerDuty alert, a timer) that launch agents on their own. The agents run, do their work, and pull a human in only when they hit something that needs judgment.
Cursor's engineering lead Jonas Nelle put it plainly: engineers "aren't always initiating. They're called in at the right points in this conveyor belt." The company says it already runs hundreds of these automations per hour on its own codebase, handling everything from bug detection to incident response to weekly changelog summaries posted to Slack.
The numbers behind it are hard to ignore. Bloomberg reported this week that Cursor's annualized revenue has topped $2 billion, doubling in roughly three months. They hold about 25% market share among generative AI tool subscribers.
Why this matters more than it sounds
On the surface, this looks like a workflow convenience. Set a trigger, let an agent handle it. Neat. But if you step back, what Cursor is actually doing is turning the AI coding assistant into infrastructure. Not a tool you open and use. A system that's always running.
That's a meaningful shift. We've gone from "autocomplete in your editor" to "background processes that commit code, review PRs, scan for security issues, and respond to production incidents while you're asleep." In about two years.
I keep coming back to the attention problem. A developer managing dozens of agents at once isn't really reviewing anything carefully. They're rubber-stamping. Automations tries to fix this by being selective about when it asks for human input. That's a good design instinct, but it also means the quality of the automation's judgment becomes load-bearing. If it decides something doesn't need human review, and it's wrong, nobody catches it.
What we're seeing in practice
From our web and API development work, we've watched the AI tooling conversation shift over the past year. Early on, clients wanted to know if AI could speed up feature development. Now, the questions are different: how do we govern what AI agents are doing across our repos? Who's responsible when an automated PR introduces a regression? How do we audit this?
These aren't hypothetical questions. In our work with enterprise clients, especially those under Swiss compliance requirements, "an AI agent did it" is not an acceptable answer when something goes wrong. You need traceability. You need to know which agent ran, what it changed, why, and who approved it.
Cursor's Automations framework does seem to understand this, at least partly. The PagerDuty integration, for example, queries logs through MCP connections and assembles a timeline before proposing a fix. That's an audit trail of sorts. But "of sorts" isn't good enough for regulated environments.
The security angle nobody's talking about
Here's what genuinely concerns me. During our penetration testing engagements with gaming studios and enterprise platforms, one of the most common attack vectors we find is automated processes with excessive permissions. CI/CD pipelines that can deploy to production. Service accounts with admin access nobody's reviewed in two years.
Always-on coding agents are the same category of risk, with more autonomy. An agent that can read your codebase, query your production logs via Datadog, open PRs, and trigger deployments is an incredibly attractive target. If an attacker compromises the trigger mechanism (say, a crafted Slack message), they potentially get agent-level access to your entire development workflow.
Cursor's Automations currently triggers from Slack messages, code changes, and PagerDuty alerts. Each of those is an attack surface. When configuring tools like Cloudflare or Akamai for DDoS protection, we always map the full chain of automated systems that can modify production state. AI coding agents now belong on that map.
What you should do right now
If your team is using or evaluating AI coding tools with automation features, here are concrete things to address this week:
Inventory your agent permissions. What can each agent read, write, and execute? Treat this the same way you'd treat a service account audit. If an agent can open PRs and query production logs, it needs the same security scrutiny as any automated deployment tool.
Define your human-in-the-loop policy before you need it. Don't let the tool decide what's important enough for a human to see. Your team should define that threshold based on risk: anything touching auth, payments, infrastructure config, or user data gets a human review. Period.
Log everything. If you're running agents that make changes autonomously, you need immutable logs of what was triggered, what changed, and what was approved (and by whom). In our work building cloud-native applications for enterprise clients, we wire this into the CI/CD pipeline from day one. Bolt it on later and you'll miss gaps.
Treat agent integrations as part of your threat model. If you're doing any kind of security review or pen test, include your AI agent configurations. In our native iOS and Android projects, we've seen teams lock down their mobile app security while leaving their development toolchain wide open. Same principle applies here.
The bigger picture
The agentic coding space is moving fast. Both major AI labs have shipped competing features in the last month, and the direction is clear: coding tools want to be always-on, autonomous, and deeply integrated into your stack.
That's probably where things are going. I'm not suggesting teams avoid these tools. We use AI-assisted development ourselves, and the productivity gains on boilerplate, test scaffolding, and routine refactors are real.
But there's a difference between using AI tools and letting AI tools run your development process unsupervised. The line between the two just got blurrier. Teams that treat their AI agents with the same rigor they apply to any other automated system with production access will be fine. Teams that don't will learn why the hard way.
We've seen this pattern before. When CI/CD pipelines first became widespread, the teams that treated them as security-critical infrastructure from day one avoided the breaches that hit everyone else a few years later. AI coding agents are at that same inflection point right now.
If figuring out how to govern AI tooling across your dev team sounds like your current headache, let's talk.