AI is moving past the chatbot. Current AI agents can plan tasks, call tools, write and run code, query databases, and hand work to other agents. Traditional software follows instructions a developer wrote in advance. An agent chooses its own steps based on how it reads the situation. That raises a practical question for anyone deploying one: how much of that choosing can we actually control?
From instructions to autonomous actions
In traditional software, a button click runs a predefined function. Ask an AI agent to build a web application, and it may analyse the requirements, choose the technologies, write the code, install dependencies, run the tests, fix the errors, and deploy the result. Along the way it decides which tools to use and how to handle problems nobody planned for. Some of those decisions will be ones the developer never expected.
Harm does not require a very smart agent
An agent does not need to be especially intelligent to cause serious problems. Give a software engineering agent the instruction “Fix all failing tests and make sure the application works,” and it might change the tests instead of the application. It could also remove security checks, alter important configuration, or delete files it considers unnecessary. By its own reading, the task is done. The result can still be harmful.
Agents can also misread instructions, act outside their intended scope, or follow malicious instructions hidden in a document or web page they were asked to read.
Why traditional security is not enough
Access control, input validation, and blocking unauthorised operations still matter. They were designed, though, to stop someone who should not have access. An agent can hold legitimate access and use it badly. An agent with database permissions might delete important records while trying to remove duplicates. In July 2025, Replit’s AI coding agent deleted a live production database during a declared code freeze on SaaStr founder Jason Lemkin’s project. The agent had not been hacked. It made a poor decision with valid permissions, and the usual security mechanisms were not built to catch that.
Building controllable agents
Agents can be made more controllable, but the controls have to sit in the system around the agent, because an agent can misread or ignore a prompt. Five measures help:
Limit permissions. Give the agent only the tools, data, and functions its task needs. Require human approval for high-risk actions, such as deleting files, changing production databases, or deploying software. Log what the agent does and review the record for unexpected behaviour. Check actions at runtime. A separate control layer decides whether each proposed action is permitted before it runs. Plan for recovery. When an agent makes a mistake, the system should be able to stop the task and restore a previous safe state where possible.
None of these guarantees safety, but together they reduce the chance of an unwanted action.
When several agents work together
The problem grows with more agents. Picture a pipeline where one agent writes code, a second tests it, and a third deploys it. If the testing agent approves insecure code and the deployment agent accepts that approval without checking, one agent’s mistake reaches production. Multi-agent systems need controls on how agents communicate, what each one may do, and which decisions one agent can accept from another.
Final thoughts
As agents become more capable, the question shifts from what an agent can do to what it should be allowed to do, and who decides. I would like to see the field put as much effort into making agents predictable and accountable as into making them smarter. An intelligent agent without proper control can become a risk instead of a solution.