What makes an AI agent safe to give real access

An AI agent is useful precisely because it can do things: look up an order, update a ticket, raise a purchase order, send an email. That’s also what makes it risky. A chatbot that gets something wrong gives a bad answer. An agent that gets something wrong changes a record.

We build agents for business systems, and the question we hear most from operations and IT teams is how to let one near real systems without losing sleep. Our answer comes down to three controls: what the agent is allowed to do, when a person has to approve, and what gets written down.

Give the agent its own, narrow permissions

An agent should never borrow a person’s login, and it should never get an admin account “to make setup easier”. Give it its own account in each system, with only the permissions its tasks need.

That sounds obvious, but it’s the step most often skipped in pilots. Then the pilot becomes production and the agent still holds every permission someone gave it during testing.

A few practical rules:

• Start read-only. Let the agent look things up and draft actions before it can carry any of them out.
• Grant tools, not systems. “Can create a refund up to ₹5,000 on an existing order” is safer than “has access to the payments system”.
• Limit the data it can see. If the agent handles HR questions, it shouldn’t be able to read payroll records it doesn’t need.

Narrow permissions also limit the damage from attacks. If someone tricks the agent with a crafted email or document (known as prompt injection), it can only misuse the tools you gave it.

Decide which actions need a person

Not every action needs approval, or nobody would use the agent. Sort its actions into two groups:

• Actions it can take on its own: reversible, low-cost and internal. Examples include tagging a ticket, drafting a reply for review, or looking up stock levels.
• Actions a person must approve: anything that moves money, changes important records, deletes things, or contacts a customer or supplier.

The approval step should show the person exactly what the agent intends to do and why, in plain language, with the data it relied on. “Approve refund of ₹3,200 to order 18842, because the customer reported a damaged item and the photo matches” can be checked in seconds. A vague “Agent wants to perform an action” gets clicked through without anyone reading it.

Set the thresholds together with the team that owns the process, and review them after a few weeks. You’ll usually find some approvals can be relaxed, and occasionally one that needs tightening.

Log everything the agent does

Every step the agent takes should be recorded: what it was asked, what it looked up, what it decided, which tool it called with which inputs, and who approved it. Store the log somewhere the agent can’t edit.

Logs serve three purposes. They let you investigate when something goes wrong. They let you show an auditor or customer how the system behaves. And they’re the best source of ideas for improving the agent, because you can see where it hesitates, fails or needs a person.

Plan for failure

Agents will meet situations they weren’t built for. Decide in advance what happens then. A good agent stops and hands the task to a person with a clear note, rather than guessing. Put limits on how many actions it can take in a row, and give the team a simple way to switch it off.

Test it like an attacker would

Before launch, test the agent the way someone malicious would. Hide instructions in a document it will read and see whether it follows them. Ask it to do things outside its role. Try to get it to reveal data from other customers. We cover this in more detail in Testing AI features before launch.

A short checklist

Before an agent gets access to a real system, you should be able to answer yes to each of these:

• It has its own account with only the permissions its tasks need.
• Actions that move money, change key records or contact people need approval.
• The approval screen explains the action in plain language.
• Every action is logged somewhere the agent can’t change.
• It hands over to a person when it’s unsure, and someone can switch it off.
• It has been tested against prompt injection and misuse.

None of this is exotic. It’s the same thinking you’d apply to a new member of staff with access to your systems, and an agent deserves at least that much care.