A commerce demo often runs on the same script.
An AI assistant finds a customer, pulls an order, checks inventory, changes an address, creates a return, issues a refund, applies a discount, then drops a note in the CRM. One conversational request. Seven systems. Everyone is impressed.
Then comes the question that matters when the demo has to become a real product:
What, exactly, was the agent allowed to do?
Most teams answer with a list of integrations. It can access Shopify. It can access the OMS. It can access the customer-service platform. It can access the CRM.
That is not an answer. It is a map of the blast radius.
In commerce, access is easy to mistake for usefulness. A broad API token makes an agent look capable because it can reach many systems and finish many flows. But a live customer journey is not a benchmark. It involves money, inventory, delivery promises, customer data, and the occasional irreversible mistake.
The agent that can do everything is rarely the first agent a business should trust.
A Customer Request Is Not a Blank Cheque
Consider a customer who writes:
“My order arrived late and the blue jacket does not fit. Can you help?”
A helpful agent needs to understand the request, find the order, check the return window, see whether another size is in stock, and explain the choices. Up to that point, the work is largely informational.
The last mile is different. An exchange can reserve inventory. A refund moves money. A replacement shipment creates a fulfilment obligation. A discount affects margin. An address change can send a package somewhere else.
Those are not just tool calls. They are business decisions with different owners, rules, and consequences.
The usual shortcut is to give the assistant a general-purpose commerce credential and tell it to use good judgment. It feels flexible. It also asks a language model to turn a messy, ambiguous message into a series of material changes across core business systems.
That is where agent design gets tangled up with permission design.
An agent may need to reason across a lot of context. It should not inherit every action that context makes possible.
OWASP calls this failure mode excessive agency. It describes the damage that becomes possible when an AI system has more functionality, permissions, or autonomy than its job requires. The remedies are straightforward: offer fewer tools, keep them narrow, enforce least privilege in downstream systems, and require approval for high-impact actions.[1]
For commerce, there is one further idea worth adopting.
Permission should describe a specific business moment, not a standing technical relationship.
The Useful Unit of Permission Is an Intent
Traditional integrations are built around systems.
The order platform gets a service account. The CRM gets a service account. The helpdesk gets a service account. The agent works with whatever those accounts can reach.
That made sense when the caller was a human employee or a deterministic workflow. It is a poor fit for an AI system that interprets fresh language every turn, reads untrusted content, and chooses its next tool as it goes.
The permission needs to be more exact:
On behalf of: Jordan Lee
For: Order #10482
May: prepare an exchange for size M
Only if: item is eligible and size M is available
Cannot: issue a refund, change the shipping address, or add a discount
Expires: when the support session ends
Requires: Jordan's confirmation before shipment is created
That is not a role. It is a delegated, time-bounded mandate.
The distinction can sound a little fussy until the agent receives a vague request, an incomplete request, or a message shaped by something hostile that it has read. A support agent that can retrieve order status is useful. One that can quietly turn a late-delivery complaint into a refund, a discount, and a replacement shipment has been given authority that does not follow from the customer’s words.
The customer did not ask the business to make every possible remedy available. They asked for help.
Permission Has Five Parts
A commerce agent needs more than a generic “can call this API” check. Before an action is accepted, the business should be able to answer five questions.
Five questions before an action is accepted
Who is acting? The agent’s identity and the user, employee, or workflow it represents. Example: a returns assistant acting for Jordan Lee, not a shared admin account.
What is it acting on? The exact customer, order, cart, product, or case in scope. Example: Order #10482, not every order linked to the customer record.
What may it do? One defined operation rather than a broad system capability. Example: create a return label, not “manage returns.”
Within what limits? Monetary, quantity, geography, and policy boundaries. Example: one unused item under the published return policy.
When is it valid? Time, session, and workflow state. Example: valid for the current support conversation, before the label is issued.
That separation is useful.
The model can conclude that an exchange seems like the right next option. It can explain why. It can ask the customer which size they want.
The commerce system should decide whether that exchange is actually permitted at that moment, for that item, under that policy, with that inventory position.
That decision should not ride on whether the model phrased its tool call convincingly.
NIST’s AI Agent Standards Initiative identifies agent authentication and identity infrastructure as a research focus for secure human-agent and multi-agent interactions.[2] That attention is well placed. When agents act for people, identity is not an implementation footnote. It is where the transaction begins.
Broad Tools Turn Ordinary Requests Into Security Problems
Here is the sort of tool list an operations agent is often handed:
get_customer(customer_id)
get_order(order_id)
update_order(order_id, fields)
issue_refund(order_id, amount)
create_discount(customer_id, value)
run_sql(query)
It is convenient for an engineer. It is a poor interface for an agent.
update_order carries hidden power. Which fields may change? Can the agent alter an address after fulfilment? Tax? The product itself? Does the update notify the customer? A tool name that hides several business decisions asks the model to infer rules that the software should enforce.
run_sql is worse. It may have a place for a human analyst in a controlled environment. It should not be part of a customer-facing assistant’s normal vocabulary.
The answer is not a longer system prompt. It is capabilities that carry their own boundaries.
Broad tool versus agent-ready capability
update_order(order_id, fields)becomesrequest_address_change(order_id, new_address)with fulfilment-state validation.issue_refund(order_id, amount)becomespropose_refund(order_id, eligible_line_items)followed byconfirm_refund(refund_id).create_discount(customer_id, value)becomesoffer_service_recovery_credit(case_id)with a policy-defined ceiling.get_customer(customer_id)becomesget_support_context(order_id)that returns only the fields needed for that case.run_sql(query)becomes a purpose-built reporting or lookup action with fixed, reviewable inputs.
The assistant has not become less helpful. The business has become more explicit.
A narrow capability can validate dates, check stock, enforce policy, apply tax logic, record the reason code, and ask for confirmation. It can explain a denial in a way an operator understands. It can leave behind an audit trail that answers more than “the API returned 200.”
A generic API call cannot do that unless every one of those concerns is rebuilt around it.
The Agent Should Assemble an Option, Not Invent a Commitment
This lands hardest in the customer journey.
There is a real difference between an agent that says, “I found your order. The blue jacket is eligible for a free exchange, and medium is available. Would you like me to send it?” and an agent that creates the replacement shipment because it has decided that is the helpful thing to do.
The first agent removes work. The second one makes a commitment.
Customers change their minds. They may prefer a refund. They may need a different address. They may want to wait for another colour. They may simply have been asking about the policy.
The agent should do the expensive reasoning and the mechanical preparation. The customer should still be part of the moment when intent becomes a commercial act.
This does not mean putting a human approval gate in front of every keystroke. That would make the product miserable. It means putting the right gate at the point where the business takes on a new obligation or changes a customer’s rights.
The pattern is simple:
UNDERSTAND → RETRIEVE → PREPARE → SHOW → CONFIRM → COMMIT
The first four steps can be highly automated. The last step should match the consequence.
Filtering products by a customer’s stated preferences might not need any extra approval. Submitting a financed order, shipping a replacement, or issuing a material refund should make the scope, price, and outcome visible before it is final.
Anthropic makes a related point in its guidance on agent systems. Use the simplest pattern that can solve the task, reserve agents for work that needs flexible decision-making, and use guardrails and stopping conditions when autonomy is necessary.[3] For commerce teams, the practical question is blunt: do we need an agent here, or do we need a well-designed workflow with a language interface?
Often, the answer is both. Let the model handle the messy conversation. Let the workflow handle the commitment.
Better Permissions Produce Better Products
There is an obvious objection. Narrow capabilities take effort to design. They force teams to name the business operations hiding behind an admin interface. They expose policy exceptions that were previously handled through experience and improvisation.
Exactly.
That is not security paperwork. It is product work.
When a team defines request_purchase_confirmation, it has to decide what the customer should see before purchase. When it defines offer_service_recovery_credit, it has to decide which cases qualify and how much discretion makes sense. When it defines create_exchange, it has to decide when stock is reserved and what happens if that stock disappears.
Those questions exist whether an agent is involved or not. Agents just make them hard to avoid.
This is why agentic commerce is not a race to give a chatbot a bigger set of credentials. It is a forcing function for cleaner service boundaries, clearer customer promises, and smaller, more legible business actions.
The best future interface may not be one bot with access to every part of the company. It may be a collection of agents, each carrying a small, temporary mandate and making its work easy to inspect.
Design for Delegation, Not Access
If you are adding an agent to a commerce workflow, start with the commitment, not the model.
Ask what the agent should be able to prepare. Ask what it should be able to explain. Ask which customer or operator needs to see the final decision. Then make the action that changes the world small enough that a policy engine, a human, and an auditor can all understand it.
It will feel a little less magical in a demo. It will be far more useful on a busy Tuesday, when the customer’s message is vague, inventory is moving, a promotion is live, and no one wants to explain why an assistant issued three refunds overnight.
That is the standard worth building toward:
Give agents enough context to help. Give them enough authority to prepare. Give them only the permission required to commit.
The goal is not a bot with the keys to the building.
It is a service that knows which door to open, for whom, and for how long.