The first wave of AI answered questions. The wave arriving now does things. It files the ticket, updates the customer record, sends the follow-up email, and connects to the line-of-business systems your company runs on. That is a different category of risk, and the time to set the limits is before the first agent gets a credential, not after the first one does something surprising.

Here’s the thing. An agent is not a smarter chatbot. It is closer to a new employee with system access and no manager standing behind them. You would never onboard a person that way. So do not onboard the agent that way either.

Set AI agent security boundaries before granting access

Separate read from write. Reading is a visibility question: what can it see? Writing is a change-control question: what can it alter, and who signed off? Those are different reviews owned by different people, and collapsing them into one “access” checkbox is how an agent that was supposed to summarize tickets ends up closing them.

Allowlist actions, not systems. “Has access to the ticketing system” is a hope. “Can update a ticket’s status and add a comment” is a rule. The difference is everything. Think of it like a valet key. It starts the car and opens the driver’s door, and that is all it does. The glove box and the trunk stay shut, not because the valet is untrustworthy but because the key was cut that way. Cut the agent’s key the same way, one action at a time.

Human approval for the actions that matter. Anything that moves money, changes someone’s access, or communicates with a person outside the company gets a human in the loop. That list is short on purpose. If you require approval for everything, the approver stops reading and the control becomes theater. Approve the few things that can hurt, let the rest flow, and be clear about which is which.

Short-lived, scoped credentials. An agent should never carry an admin’s token. It should carry a credential that does exactly its job, expires soon, and can be revoked in one step. If the agent gets compromised or simply goes off script, the damage is bounded by what that credential could do in that window. A long-lived admin credential in an agent is the same as leaving the master key in the ignition.

Log every action. What was requested, what was actually done, and who approved it. Not a summary, the actual record. This is how you answer the question you will eventually get asked: “the customer says their record changed, and nobody on the team touched it.” With the log, that is a lookup. Without it, that is an incident.

The key thing is to start with one system. Pick the integration with the smallest blast radius, wire up the read side, then allowlist a couple of write actions with approval, run it for a while, and read the logs. Test that each integration supports the intended permissions, approvals, and records. Then expand. Each new agent needs that same validation before it inherits the pattern, and the pattern is where the safety lives.

So basically the rules for an agent are the rules you already have for a contractor with a laptop, written down before the contractor starts. The only difference is that this contractor works at machine speed, which is exactly why the limits have to be in the system and not in a meeting.

Practical next step: list every place an AI tool in your company can currently write to a system, not just read. If the list is empty, good, you are early. Write the allowlist for the first one before it exists. If the list is not empty and nobody can produce it, that is the project for this week.

Where Ovatio fits

Ovatio Comply can allow, deny, or hold supported requests routed through it under configured policies. Your connected systems retain their own identity and authorization requirements.