Key takeaways
- Separate read, propose, create, modify, publish, send, pay, and delete capabilities; “CRM access” is not a useful permission level.
- Bind each action to the requesting user or service identity and the smallest practical data scope.
- Require deterministic policy checks and explicit approval for sensitive, irreversible, or high-impact actions.
- Remove abandoned tools and expired scopes; permissions accumulate quietly when nobody owns the inventory.
01
Inventory verbs, not vendor logos
A box marked “HubSpot” or “Google Drive” hides the decision that matters. Can the agent search contacts, read every property, overwrite lifecycle stage, export a list, send a message, or delete a file? Write down the exact tool methods, resources, and identities available in production.
NIST describes agent tool access in terms such as read-only, constrained write, and write, across trusted and untrusted environments. That is a useful start, but an operating matrix should go further: identify the affected record, maximum volume, data sensitivity, reversibility, cost, and whose authority the action uses.
02
Use a ladder of authority
Begin with observe-only access. The next level can draft or propose an action without executing it. Constrained execution should use narrow methods, allowlisted fields, rate limits, and record-level checks. Publishing, sending, paying, deleting, changing permissions, and bulk updates should sit behind stronger confirmation or remain unavailable.
Do not rely on a prompt that says “be careful.” OWASP calls excessive functionality, permissions, and autonomy root causes of excessive agency. Enforce the boundary outside the model with authentication, authorization, schemas, policy code, and downstream controls.
Swipe to compare every column
| Capability | Default mode | Control before execution |
|---|---|---|
| Read approved records | Automatic | Tenant, field, and row scope |
| Draft an update | Automatic | Schema validation and provenance |
| Write a reversible field | Constrained | Policy check, idempotency, audit log |
| Send, publish, pay, delete, or bulk-edit | Approval required | Preview, named approver, fresh authorization |
03
Carry user authority through every tool call
An agent acting for one salesperson should not inherit a shared administrator token. Use delegated credentials where possible and verify the subject, tenant, resource, purpose, and permitted operation again at the tool boundary. A valid token is not proof that this action fits the current task.
Store the authorization decision beside the action: policy version, requesting identity, approved scope, arguments, result, and any human confirmation. That makes later review possible without logging hidden reasoning or retaining more personal data than the investigation needs.
04
Review access as the workflow changes
Re-run the matrix when a tool, model, prompt, connector, data source, or use case changes. Remove trial integrations after the experiment. Test denied actions as deliberately as successful ones, including cross-account access, bulk requests, stale approvals, and instructions embedded in retrieved content.
The safest agent is not the one with the longest warning prompt. It is the one whose available actions make a costly mistake difficult, visible, and recoverable.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
