13 Boundaries Every AI Agent Needs (And Most Don't Have)

AI agent boundaries are the written limits on what an agent may read, what it may say, what it may do on its own, and when it must stop and hand off to a person. Every production agent needs them, and most do not have them in writing, which means the agent's own judgment fills the gaps.

The reason boundaries matter comes down to what agents cannot do. They cannot carry accountability, keep a promise or judge what a company stands for; the guide to what AI agents cannot do explains why. Boundaries are how a team keeps those calls with people.

The 13 boundaries

1. Action scope

List the actions the agent may take, and treat everything else as forbidden. "May open tickets and add comments" is a boundary. "Can help with tickets" is not.

2. Data access

Name the systems the agent may read and the ones it may never read. Give it the narrowest access that lets it do its job, through its own account, so its access can be reviewed and removed on its own.

3. Cost ceiling

Set a limit on what one task or conversation may cost, in model usage or in money the agent can commit. An agent stuck in a loop can spend a month's budget overnight.

4. Time limits

Decide how long the agent may work without a person checking in. An hour-long autonomous task needs a different level of trust from a ten-second answer.

5. Decision classes

Sort decisions into those the agent may make, those it may recommend, and those it must leave to a person. Anything costly or impossible to undo belongs in the last group.

6. Topic scope

Say what the agent is for, and what it should decline to discuss. A support agent should not give legal advice or comment on a colleague's performance.

7. Tone and content

Write down what the agent must never say: promises about pricing, guarantees about dates, opinions about people. These are the lines a person would know not to cross without being told.

8. Identity

People should always know they are dealing with an AI tool, and on whose behalf it is speaking. An agent that sounds like a person, or writes as if it were a named colleague, breaks trust the first time someone finds out.

9. Escalation triggers

List the situations where the agent must stop and hand off: an angry customer, a request outside its scope, a question it cannot answer from its sources, any mention of legal or safety issues. Name who it hands off to.

10. Memory

Decide what the agent may remember between conversations, for how long, and who can see it. Unbounded memory turns a helpful tool into a store of things people never meant to keep.

11. Versions and updates

When the model, prompt or tools change, the agent's behavior changes. Treat each change like a software release: test it, record it, and know how to roll it back.

12. Integrations

Each tool the agent can call is a new way for it to act. Approve integrations one at a time, and review the list whenever a new one is added.

13. Outcomes

Name the person accountable for what the agent produces. If its output goes to customers, someone reviews a sample. If it changes systems, someone owns the result.

Enforce boundaries in the platform, not only the prompt

A boundary written only in the agent's instructions is a request, not a limit. A cleverly worded message, a confusing document in its context, or a model update can talk the agent past it. The boundaries that matter most should be enforced by the system around the agent:

• Access: the agent's account simply cannot read what it should not read.
• Actions: the tools it can call allow only the permitted actions, with limits built in.
• Approval: risky actions wait in a queue for a person to approve.
• Cost and time: hard limits stop a task when it hits them.
• Records: every action and answer is written to a log the agent cannot change.

Keep the instructions too. They shape tone and behavior. But assume that anything enforced only by instructions will eventually be broken.

Questions to answer before you deploy

Before an agent goes live, the team should have written answers to these questions:

1. What single job is it for, and what is out of scope?
2. Which systems may it read and change?
3. Which questions or actions must go to a person, and to whom?
4. What does it do when it does not know?
5. Who is accountable for its results?
6. How will we find out it is wrong?
7. Who can turn it off, and how quickly?

The AI agent boundaries checklist turns these into a table you can copy, and the AI agent readiness check scores how ready your team is.

Signs you are not ready for an autonomous agent

• Nobody can say who would answer for a wrong action.
• The agent would need broad access because nobody has mapped what it needs.
• Your team's decisions and rules are not written down, so the agent would have to guess them.
• There is no way to see what the agent did yesterday.
• The pilot succeeded because one person watched every step, and they are about to stop.

Any of these means the boundaries are not ready, even if the agent is. Start with a narrower scope, or with a tool that answers and hands off rather than one that acts.

Who owns the boundaries

Boundaries need an owner, or they decay. The owner reviews them when the agent changes, signs off on new access, and makes sure the accountable person still exists. In many companies that role sits with whoever owns AI policy; see who owns AI policy. Once an agent is live, the patterns in how AI agents fail tell you which boundaries to check first.

Where StandIn fits

StandIn is not an agent. It answers your teammates' questions from the work you have already done, and its limits are built into the system: it reads only the tools you connect, read-only, writes nothing into your tools, and takes no actions on your behalf. When the answer is not in your work, it never guesses: it says so and points to the person who knows. Read how StandIn's boundaries work.