Permission design gets harder when the actor is an agent. A human has intent, context, reputation, and accountability. An agent has delegated authority. That authority needs shape.
The lazy answer is to give the agent the user's permissions and hope the prompt behaves. That may work for trivial tasks. It is a bad foundation for real work. The agent should not inherit unlimited reach just because a human clicked “connect.” It needs scoped permissions, bounded tools, sandboxes, approval gates, and clear logs.
The goal is not to suffocate the agent. The goal is to create trust loops.
A trust loop lets the agent earn more autonomy by operating safely inside a boundary. Start with read-only access. Add dry-run planning. Allow low-risk actions. Require approval for customer-facing, financial, destructive, or broad changes. Monitor outcomes. Expand scope where the pattern is reliable. Pull it back when errors appear.
This is product design, not only security design. If the permission model is too crude, useful work gets blocked or dangerous work gets allowed. “Can access CRM” is not a meaningful permission. Can it read all accounts? Export data? Change lifecycle stage? Contact a customer? Create tasks? Modify owner fields? Act on enterprise accounts? Use data from one customer to help another?
Sandboxes matter because agents need places to test plans. A sandbox can be a fake environment, a draft mode, a local simulation, a staging account, or a preview queue. The common idea is simple: let the agent practice the move before it touches production reality.
Approval should also be designed carefully. If every action needs approval, the system becomes theater. If no action needs approval, trust breaks at the first serious mistake. The right review point is usually the boundary between preparation and consequence. Let the agent gather, analyze, draft, and propose. Pause before sending, deleting, spending, committing, or escalating externally.
Agent-native tools make this visible. They do not bury authority in OAuth scopes and admin pages. They expose what the agent can do, what it did, and what it needs from a human next.
Delegation without boundaries is anxiety. Boundaries without delegation are bureaucracy. The product has to hold both.
This is part 8 of 10 in Agent-Native Tools.
