How do you control AI coding agents in real company environments without blocking productivity?
Hi everyone,
We’ve started rolling out AI coding tools like Cursor in a mid/large company across engineering and operations teams, and we’re running into a core issue:
These tools can generate actions that go far beyond “code suggestions” — they can directly impact real systems and business-critical data.
For example:
A developer could accidentally delete or overwrite important code or infrastructure changes
A finance or operations user could make a wrong transformation in Excel or similar files that causes serious business impact
AI-generated commands could modify databases, Kubernetes clusters, or production environments in unsafe ways
Things like running destructive Docker commands (e.g. docker system prune) or deleting local files that might be important (like Excel sheets used in reporting workflows)
At this point, we don’t want to block or slow down our employees unnecessarily.
But at the same time, I want to prevent critical mistakes that could easily slip through unnoticed when using tools like Cursor.
So the real question we’re struggling with is:
How do you actually keep control of this in practice?
Do you fully filter or gate everything AI suggests before execution?
Do you restrict what AI tools are allowed to do at a system level?
Or do you rely on developers and users to manually verify everything every time?
In other words, how are you preventing AI tools from becoming “too powerful” in day-to-day company workflows without completely killing productivity?
Am I being a bit paranoid here, or is this a real concern in production environments?
Would really appreciate hearing how others are handling this in real setups.
Şu anda temel modelimizi kullanıyorsun
Daha fazla zekâya erişmek için bir hesap oluştur veya oturum aç.
Interesting questions of which the survival or thriving of the whole company could rest.
drop that into a chatbot. and create some research prompts to get started now. I read a book called the unicorn project, its an easy read but it will surface problems that are going to come up and the kinds of people it will take to solve them. It’s dated but a fast read.
A lot of basic management problems are dependent on founder values, responsibility and permissions, and pre-established communications channels and protocols, business processes.
You are going to need automated pipelines that do testing and qa but before this is all over but I would think you do need some temporary restrictions and some compartmentalizations to keep the blast radiuses localized. , your fears are not unfounded. I personally believe in personal responsibility and authority but creativity thrives in a safe environment.
I noticed recently that Anthropic did not fire the person that leaked claude code, instead they chose to fix the problem instead of playing the blame game. These are the kinds of management styles that don’t travel well when everyone is afraid to lose their job. That’s systemic domain issues. But it addresses creativity. Mistakes will be made, rockets will blow up.
Hey, that’s a totally valid request, not paranoia. Cursor gives you a few layers of control, so you can mix them depending on how strict you need isolation to be.
Deterministic security controls (hard gates)
This is what you should rely on first, because LLMs can’t give guarantees.
Allowlist and denylist for the terminal in Auto-Run. You specify which commands the agent can run without confirmation, and everything else needs manual approval. You can explicitly put rm -rf, docker system prune, kubectl delete, and similar commands on the denylist.
Hooks. These are programmable policy gates that trigger before an action runs. For example, beforeShellExecution blocks a command at the policy level, not at the prompt level, so the agent can’t talk its way around it. Cursor supports both code-based and prompt-based hooks. This is also where Snyk Evo Agent Guard can plug in for real-time checks. Docs: Hooks | Cursor Docs
Sandboxing and Cloud Agents. If you want destructive operations to have zero access to your local machine or prod environments, run agents in an isolated environment.
LLM steering (soft layer)
Rules at the user, project, or team level. These set conventions and constraints in context. It’s not a guarantee, but it lowers the chance the agent will try something risky. Docs: Rules | Cursor Docs
Enterprise governance
If you’re on Business or Enterprise, you get centralized policy management, audit logs, SSO and SCIM, and control over which models and integrations are allowed. Overview:
A practical setup that usually works in mid and large companies is this: prod isn’t accessible from the IDE at all, for either the user or the agent. Access happens only through CI and CD with policy-as-code and service accounts. The local dev environment is isolated, and in Cursor you enable hooks plus a denylist for destructive commands. That way you don’t have to control the AI. The agent just physically can’t reach the place where it could do damage.
This is a big part of what we do. Ultimately, having people who are actually professional developers double-checking the AI’s work is very important; treat it like a junior developer.
master branch is protected, no one can push directly to it (including AI agents)
PRs require human review/approval before merging
human review process for all PRs regardless of source
We also use the Bugbot tool that @Robert_Howard mentioned, it’s quite good.
We call these operations “cowboys” and we also do a human review process before they can be run in a production environment.
Human review slows down everything but it’s worth it, and we’re still moving so much faster than before AI tools were available.
You’re not paranoid at all, this is a real production concern. My approach is basically: don’t try to fully control the agent, control the environment around the agent.
94% of our code is written with Cursor AI, and one thing I learned is that AI agents work best in systems that are highly verifiable and resettable.
In practice, I would never give AI direct unrestricted production power. Instead:
Production access is heavily restricted
AI mostly works in local/staging/sandboxed environments
CI/CD, tests, linters, and reviews act as verification layers
Dangerous operations require human approval
Important infra/data should always be recoverable and versioned
The key mindset shift is:
AI agents are becoming autonomous minions with terminal access, not just autocomplete.
So the real solution is reducing blast radius instead of manually checking every tiny action.
In my presentation I talked about this idea that software engineering is actually highly verifiable because we already have infrastructure like tests, build systems, observability, security checks, docs, and reproducible environments.
The companies that struggle the most with AI agents are usually the ones with:
weak tests
flaky infrastructure
undocumented systems
inconsistent patterns
no staging/review flow
AI amplifies both strong and weak engineering culture very fast.
I want to highlight a point that @helldark and @troehrkasse already said well above: in practice, it’s more effective to control the environment, not the agent itself. Prompt-level limits are a soft layer, you can talk the agent into ignoring them. But protected branches, PR review, a denylist in Auto-Run, and Hooks beforeShellExecution are deterministic gates the agent literally can’t bypass.
If you haven’t checked them yet, here are the key docs:
