An agent’s job description includes its permissions

A useful way to describe an AI agent is to write down the decisions it can make without asking. Reading a support ticket, drafting a reply and issuing a refund may sit next to each other in a workflow. They carry very different consequences.

Google Cloud’s July 7 enterprise guide treats identity, delegated access, sandboxes and oversight as central parts of deploying agents. It describes systems operating under a user’s identity, an independent identity or delegated authority. That is a concrete starting point for implementation.

The design question is where to draw the boundaries, then how to make those boundaries survive a mistake by the model.

A refund is several decisions

Take a hypothetical support agent handling a late delivery. To answer the customer, it might need an order record, tracking data and the applicable refund policy. To return money, it also needs a permitted amount, a destination and a way to establish that the refund has not already happened.

A broad instruction to resolve the complaint leaves those decisions implicit. A narrower system can permit reading the order and preparing a reply, while requiring a separate check before moving money. The policy might allow a small credit automatically and send larger amounts to a person. The exact threshold is a business decision; enforcing it belongs in the surrounding software.

Repeated execution creates another problem. Suppose the payment service processes a refund but the network fails before returning confirmation. An agent that interprets silence as failure could retry. The workflow needs a durable transaction record and a duplicate-prevention mechanism. Better wording in the prompt cannot establish whether the first payment went through.

Approval needs a defined object

Human review is often described as though it solves the problem by itself. Its value depends on what the person actually sees. Approving “handle this complaint” is broad delegation. Approving a particular message and a particular credit to a particular customer is a bounded decision.

If the message or payment changes after approval, the earlier approval should no longer apply. This is straightforward to describe and easy to omit from a prototype. It becomes consequential as soon as generated work reaches customers.

The interface should also make the remaining uncertainty visible. A reviewer who sees only a confident summary cannot check whether the agent matched the right account or applied the right policy version. The relevant evidence needs to be available at the decision point.

There is a sensible order for expanding an agent’s remit. Start with a task whose outcome can be checked. Record exceptions and the time spent resolving them. Grant additional authority when the team can explain both the expected path and the recovery path.

A support workflow becomes more useful when it resolves the customer’s problem, records what happened and leaves the company able to correct an error. The permissions are part of that product.