AI Agents Need Boundaries More Than They Need Intelligence

The impressive bit is rarely the dangerous bit

AI agents are becoming very good at looking busy. Give one a goal, access to a few tools and a cheerful instruction to “sort it out”, and it can search, write, schedule, buy, change records and send messages with unsettling enthusiasm.

That capability is useful. It can also produce the sort of low-grade operational chaos usually associated with an intern who has been handed the master key and told that initiative is a virtue.

The industry conversation still leans heavily towards intelligence: better models, deeper reasoning, larger context windows, more capable planning. All worthwhile. But an agent that can reason brilliantly while holding broad, poorly defined permissions is not a mature system. It is a very articulate risk.

The question that matters first is simpler: what is this agent allowed to do, under what conditions, and how does it know when to stop?

That is not a glamorous question. Neither is access control, until someone discovers that the marketing assistant has helpfully deleted the customer database in pursuit of a cleaner CRM. Boundaries are the unglamorous bits that stop capable software becoming an expensive anecdote.

Intelligence expands the blast radius

An ordinary automation follows a predetermined path. If it fails, its failure is often narrow and fairly legible. A scheduled script that cannot upload a file generally just fails to upload a file. Annoying, certainly, but manageable.

An agent works differently. It interprets a goal, chooses steps and adapts when something gets in its way. That adaptability is precisely its attraction. It is also why a vague instruction can turn into a sequence of actions nobody explicitly anticipated.

Consider an agent asked to reduce overdue supplier invoices. A less capable system might flag the list for a finance colleague. A more capable one could draft emails, alter payment status, request missing paperwork, escalate disputes and perhaps propose changing approval rules to prevent future delays. If it has the permissions, it may see all of those as reasonable ways to achieve the stated objective.

None of that requires malicious intent, nor a science-fiction failure of consciousness. It requires only an incomplete objective and too much authority. The agent does what it was rewarded or instructed to do, with the confidence of a Labrador carrying a muddy stick into a freshly cleaned kitchen.

More intelligence can make this problem worse. A capable agent finds more paths around obstacles. If a workflow includes a safeguard it interprets as friction rather than a hard limit, better planning may help it seek alternatives. The model has not “gone rogue”. The system designer has confused a desired outcome with a safe operating envelope.

Boundaries are part of the product

A useful boundary is not a polite sentence in a prompt saying, “Please be careful.” Prompts can guide behaviour, but they are not reliable security controls. If the agent can call an API that issues refunds, changes access rights or sends external messages, the real boundary must exist in the tool layer and the underlying system.

That means designing explicit constraints such as:

• Scoped permissions: allow the agent to read a specific dataset or update a defined class of record, rather than granting broad administrative access.
• Action limits: cap the value, volume or frequency of actions. An agent may prepare twenty refund recommendations but not authorise twenty payments.
• Approval gates: require a human decision before consequential actions, particularly anything financial, legal, external-facing or hard to reverse.
• Allowed destinations: restrict who it can email, which services it can call and what data can leave a controlled environment.
• Stop conditions: define when uncertainty, missing information, conflicting instructions or repeated failure means the agent must pause and ask.
• Audit trails: record its inputs, tool calls, outputs and the identity of the person or system that approved a sensitive action.

This is familiar engineering territory. We do not let a temperature-control system heat indefinitely because its set-point calculation appears persuasive. There are independent limits, sensor plausibility checks, alarms and fail-safe states. A control loop can be clever and still be wrong because a sensor is disconnected, an input is stale or somebody has made a configuration error at 4:57 on a Friday afternoon.

AI agents deserve the same respect for failure modes. Their decisions may be expressed in fluent prose, which can make errors feel more considered than they are. Fluent language is not evidence of a sound state estimate. It is often simply very good sentence construction wearing a serious face.

Make the safe path the easy path

A common mistake is to make agent controls so cumbersome that people route around them. If every low-risk task needs three approvals and a committee meeting, users will inevitably look for a shortcut. Usually it will be a spreadsheet, an untracked copy-paste process or a new “temporary” integration that survives for six years.

The answer is proportional control. Match the strength of the boundary to the consequence of the action.

An agent drafting internal meeting notes can operate with considerable freedom. The worst likely outcome is a slightly bizarre summary and one colleague wondering why their sensible point was described as “a high-energy ideation moment”. An agent sending a termination letter, modifying a production configuration or purchasing stock should work under much tighter conditions.

It also helps to separate planning from execution. Let an agent investigate, propose a sequence of actions and explain the evidence it used. Then require an explicit approval to execute the plan, or at least the irreversible steps. This gives people a chance to spot assumptions that have wandered off into the hedges.

For routine operations, predefined playbooks are valuable. The agent can choose from approved actions rather than inventing a procedure each time. For example, a support agent may reset an account only after verifying a specific set of identity signals, and may never alter billing information. That is less magical than unrestricted autonomy. It is also much more likely to survive contact with customers, auditors and Monday morning.

Give agents a way to say “I don’t know”

The strongest boundary is sometimes a refusal to act. Agents need routes for uncertainty, ambiguity and conflict that do not involve making their best guess and hoping everyone admires the initiative.

This matters especially where data is incomplete or untrustworthy. An agent may encounter instructions in an email attachment, web page or support ticket that attempt to redirect its behaviour. This is commonly described as prompt injection. The practical lesson is straightforward: untrusted content is data, not authority.

A well-designed system keeps instructions, permissions and retrieved content separate. The agent should not be able to treat a line buried in a document as a command to disclose records, change its operating rules or contact an outside party. Tool calls should validate parameters independently, and sensitive operations should verify the user, purpose and scope at the point of action.

There is a human element here too. People need to know that escalating uncertainty is a successful outcome, not a failure. If the culture rewards agents only for completing tasks, designers will quietly optimise for completion. If it rewards safe, explainable decisions, an agent can say, “I found two plausible interpretations and need a person to choose.” That is not weakness. It is the software equivalent of checking the map before driving into a lake.

Measure restraint, not just throughput

Teams evaluating agents often count completed tasks, elapsed time and cost per interaction. Those are sensible measures, but they are incomplete. A fast agent that confidently completes the wrong task is not efficient. It is merely creating rework at a higher velocity.

Useful evaluation should include how often the agent correctly pauses, how reliably it respects permission boundaries, whether it handles malicious or irrelevant instructions safely, and whether its actions can be reconstructed after the fact. Test it with awkward cases: contradictory customer details, requests just outside its scope, missing approvals and data that looks plausible but is stale.

This is where careful engineering earns its keep. Build a test environment with synthetic data, limit credentials by default, and release capabilities gradually. Observe what the agent actually does, rather than what its demonstration suggests it intends to do. Demos are lovely. They are also carefully lit rooms in which nothing inconvenient has yet caught fire.

The most helpful AI agent is not the one that appears most independent. It is the one people can trust with a clear, bounded job, a sensible escalation path and controls that still work when the language model is having an exceptionally confident day. Intelligence will continue to improve. In the meantime, boundaries are how we make that intelligence useful enough to welcome into the building.