Before connecting an AI agent, write down what it can reach and what happens when it makes the wrong decision. That tells you more than any argument about how intelligent the model appears.
An agent that drafts a support reply has a different risk profile from one that can send it, refund the customer and edit the billing account. Treat those as separate permissions even when one product bundles them behind a single connection button.
Start with the smallest useful action
Give the agent the minimum access required for the current job. If it needs to summarise analytics, begin with read-only analytics access. It does not need deployment rights, customer email or domain control because those services belong to the same business.
Expand access only after the limited workflow is reliable and the value is clear.
Separate reading, preparing and acting
A practical permission model has three levels:
- Read information and produce a recommendation.
- Prepare a change for a person to review.
- Execute the approved change.
Most new workflows should begin at the first or second level. Moving to execution should depend on the reversibility and cost of a mistake, not enthusiasm for automation. The companion guide on when an agent should remain read-only gives five situations where that boundary should be permanent.
Put boundaries around consequential actions
Require human approval before publishing publicly, sending external messages, deleting data, changing permissions, moving money or committing to a contract. Use spending limits for paid APIs and narrow scopes for connected accounts.
For repeatable low-risk actions, define exact limits: which records, which project, how many items and what time window. “Manage the website” is not a useful boundary.
Keep an evidence trail
Record the request, tools used, important outputs, approvals and final action. Logs should help an operator answer what changed and why without exposing passwords or secret values.
Also define an emergency stop. The operator should be able to revoke the connection or disable execution without depending on the agent itself.
Watch the failures, not only the demo
A polished demonstration shows the successful path. An operational review asks what happens with incomplete data, a provider outage, conflicting instructions or an unexpected bill.
Good permission design is usually uneventful. Access stays narrow, approvals remain visible and the operator knows how to switch the connection off. That is the version of automation I would trust to keep running after the demonstration ends. To evaluate the surrounding architecture, map the models, tools, identity, state and logs underneath the agent.