Safe limits are enforced by the systems around the agent, not by its instructions.
An AI agent decides what to do based on its instructions and the information in front of it. Both can go wrong. Instructions can be misread, and information can be misleading or deliberately crafted, as when a customer email contains text designed to redirect the agent. Telling the model to stay within limits is not the same as limiting what it can do.
Real limits live in the software between the agent and your systems. The agent can only call actions that exist, each action checks who is asking and what they are allowed to do, consequential actions wait for a person, and every call is recorded. If the model makes a poor choice, those controls stop it or make it visible and reversible.
This is the same principle businesses already apply to people and to other software. A new employee does not get administrator rights on the first assignment, and an integration does not get access to tables it has no reason to touch. An agent deserves the same treatment, with the added care that it can act at a pace no person can.
Write down the actions the agent may take, and the limits on each.
Start with a written list. Each action has a name, a description, the systems it touches, the inputs it accepts, and its limits: record types, customers, values, and times. Look up an invoice. Draft a reply. Create a return below a set value for standard products. Anything not on the list is simply unavailable to the agent, however the request is phrased.
Keep actions narrow. An action that updates any field on any record is hard to reason about and hard to audit. An action that changes a delivery date on an open order, within a permitted window, is easy to test and easy to explain. Narrow actions also make approvals meaningful, because the approver knows exactly what they are agreeing to.
The list is a business document as much as a technical one. The people responsible for the process should agree on it, the security team should review it, and changes to it should be recorded. When someone asks what the agent is allowed to do, the answer should be a page they can read, not a prompt only an engineer understands.
Enforce the requesting person’s permissions on every action.
An agent that acts for many people should act with each person’s permissions, not with one powerful service account. When a representative asks the agent for an account’s history, the integration layer checks that representative’s access in the source system or directory before returning anything. A manager may see more; a contractor may see less.
Take identity from the business’s existing sign-in system and pass it with every request. Avoid rebuilding roles inside the agent, where they drift from the real ones. Where the source systems already enforce permissions, respect them, and where they do not, define the rules once in the integration layer so they apply to every action consistently.
Credentials for the underlying systems belong in managed secret storage and should grant only what the listed actions need. Read-only accounts for lookups, narrowly scoped accounts for writes, and no administrator keys. Test the permissions with accounts from different roles as part of every release, because a permission mistake is the most serious kind an agent can make.
Require a person to approve anything consequential.
Sort actions by what happens if they go wrong. Reading and drafting are low risk. Changing a price, issuing a credit, canceling an order, sending something to a customer, or changing a regulated record is consequential. Those actions should stop and wait for a named person to approve them before anything changes.
A good approval shows the approver what they need to decide: the proposed change, the request that prompted it, the records the agent relied on, and its reasoning. It should happen where the approver already works, such as the ticketing system or a message in Microsoft Teams or Slack, and the decision should be recorded alongside the action.
Approval thresholds can loosen with evidence. If a category of action is approved without changes over a long run of cases, the people responsible may choose to let it run automatically below a limit, with sampling. That decision should be deliberate, written down, and reversible, not something that happens because reviewers started clicking approve without reading.
Keep an audit trail and a way to switch the agent off.
Record every call the agent makes: who asked, what the request said, which action ran, with which inputs, what the system returned, whether a person approved it, and what changed. Store the record where your team can search it and keep it for as long as your policies require. This is what lets you investigate a mistake, answer an auditor, and improve the agent.
Monitor the agent as you would any system the business depends on. Watch for failed actions, unusual volumes, requests that look like attempts to manipulate it, and changes in cost. Give one person on your side responsibility for the agent, including the authority to adjust its limits and review what it has done.
Finally, make it easy to stop. A switch that disables the agent, or a single action, without affecting the systems it uses is a basic control, not an admission of doubt. Baybloom builds agents with these controls in the first release, because an agent that cannot be limited, reviewed, and switched off is not one a business should rely on.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project