Your AI agent's permissions should depend on the amount

Your access system was built for people who sign in once and work all day. An agent makes a fresh decision with every tool call, and the right answer depends on what that call is about to do.

What happened

An opinion piece in Infosecurity Magazine argues that agentic AI needs a new approach to identity and access management. The argument is simple. A person authenticates once and then acts many times inside a session, and identity systems were designed around that habit. An agent acts one tool call at a time, and whether a given call should go through depends on details a login never sees, such as how much money moves and where it goes.

The piece cites IBM research in which more than two-thirds of executives expect AI agents to take independent actions in their businesses by 2027. It repeats IBM's warning that agents tend to pick up privileges nobody explicitly gave them. And it asks for approvals that can happen asynchronously and land in an audit trail that can't be altered, in place of the sign-in-and-go model built for staff.

Why this matters to your business

Think about the refund a support rep can issue today. A rep might be allowed to refund up to $50 without asking anyone, with anything larger going to a supervisor. That rule lives in a policy document and in the rep's head, and it holds because the rep follows it. Give the same refund tool to an AI agent with an API key, and the key says yes to $50 and yes to $5,000 alike. The limit you relied on has gone, and nobody decided to remove it.

The cost shows up in two places. One is the bad action itself: a credit applied to the wrong account, or a replacement shipped to an address the customer changed an hour earlier. The other comes later, in the review. Someone will ask who approved it, and "the agent had access" won't satisfy a finance team or an auditor.

Taking the tool away throws out the reason you built the agent. What you want is the old limit back, enforced by the system instead of remembered by a person.

Why this is a CX-Builder use case

The check belongs in the flow, in the gap between the moment the agent proposes an action and the moment the action happens. CX-Builder lets you build that gap. The agent reads the request and the order history, then proposes a refund with an amount and a destination. A condition step checks that proposal against rules you wrote. Small refunds back to the original payment method go straight through. Anything large, or headed to a new account, stops.

When it stops, the flow pauses and waits for a person. That is the asynchronous approval the article asks for. A supervisor sees the proposed action, the amount and the agent's reasoning, approves or rejects it when they get to it, and the run carries on from where it paused. The customer hears that the refund is with a supervisor, which beats silence. Every run is recorded, so when someone asks who approved what, there is an answer.

CX-Builder is self-hosted, so the rules and the record sit on your own infrastructure, where your security team can read them and your auditor can ask for them.

What this looks like if you build it

It is one agentflow. The refund call is a tool that only the flow can fire, after the check. The agent produces a structured proposal with fixed fields for amount, recipient and reason. A condition node reads those fields against your thresholds, and the high-value branch runs into a human input node that holds the run until someone approves. Start the thresholds low and raise them as the approval history shows the agent getting it right.