AI Agent Tool Permissions and Risk

A support agent that needs to draft a reply should not inherit the mailbox owner's ability to forward every conversation. That sounds straightforward until a connector exposes both operations under one credential and one broad tool name.

Classify permissions by the action and target the runtime can reach. The intended task does not reduce an overbroad token's authority. Start with read, draft, write, delete, send, execute and deploy, then separate permissions further when the destination or business effect changes.

OWASP's agent security guidance addresses tool access and least privilege. The practical question is what a particular credential, application check and downstream service allow this agent to do.

Write the permission as an operation

“CRM access” is too broad for a review. “Update the internal note on a ticket assigned to this user, within this tenant” identifies something an engineer can implement and test.

Action	Permission to define	Control to examine
Read	Which records and fields may enter the workflow?	User, tenant and resource authorization before disclosure.
Draft	Where can a draft be stored and who can see it?	Scoped storage; no implicit permission to send or publish.
Write	Which fields and state transitions may change?	Typed inputs, current authorization and business rules.
Delete	Which objects may be removed, and can they be restored?	Explicit scope, retention rules and required approval.
Send	Which recipients may receive which content?	Destination and attachment checks; approval or a bounded automation policy.
Execute	Which code or commands may run with which resources?	Process isolation, network policy and constrained credentials.
Deploy	Which artifact may reach which environment?	Release authorization tied to the artifact and target.
Approve	Which business decision may this workflow authorize?	A separately defined authority, amount or scope limit, and approver relationship.
Remember	Which facts may persist across sessions?	Write authority, tenant scope, provenance and expiry.

A draft still contains data. An internal send can disclose a restricted matter to a broad channel. A read operation can return an entire customer archive. Action classes help organize the review; they do not determine severity by themselves.

Use a tool contract the provider can actually enforce

For each tool, record its allowed targets, credential, application checks and failure behavior. This small example separates two operations that a mail connector might otherwise expose together:

Tool	Allowed target	Credential and application rule	Expected denial
`draft_reply`	The current support thread	Delegated mailbox access plus a server-side check on ticket assignment and tenant	A draft for an unassigned ticket is refused.
`send_reply`	The approved recipients and attachments for that draft	The same identity plus current send authority and an approval bound to the message	Changing a recipient or attachment invalidates approval.
`update_customer`	Approved fields on the assigned account	Resource-level policy; provider access alone is insufficient	A tenant change or a billing-field update is refused.
`deploy_preview`	The specified preview project	A preview-scoped role and artifact check	The same request cannot select production.

The scope in this table is an application requirement. It is not necessarily an OAuth scope the provider supports. User-delegated access can improve attribution while still allowing far more than one ticket or thread. Verify the resource checks separately.

Remove unused tools and credentials. If a workflow requires a service account, constrain it to the job and preserve the initiating user's identity in the authorization decision. A blanket preference for user tokens does not replace this work.

Validate writes against current state

A correctly typed patch can still modify the wrong record. Before execution, check the tenant, target, permitted fields and current workflow state. Recheck when a proposal has been waiting for approval; the user's access or the record may have changed.

Bind approval to the exact consequential operation. The binding may include the action, target, parameter digest, approving identity and expiry. Keep enough protected content or source references to explain what was approved: a digest alone cannot reconstruct a missing message.

For destructive actions, production releases and changes to access or money, define the business authority explicitly. Some organizations require a human decision for every operation. Others permit automation within narrow limits. The model must not be able to grant itself either permission.

Review sends as data transfers

A useful default for a new support workflow is:

Generate draft
  -> validate recipient and content
  -> obtain approval for this message
  -> send through the authorized identity
  -> record the downstream result

A mature bounded workflow may automate the approval step under an agreed policy. It still needs destination checks, limits and a way to stop. Test a private attachment added to an otherwise permitted message, an internal channel with broader membership, and a recipient changed after approval.

Do not infer delivery from the model's response or from the absence of an error. Preserve the provider operation identifier and reconcile uncertain outcomes before retrying.

Follow data across tool calls

The permission review cannot end at each tool's schema:

search_customer_records
  -> summarize_sensitive_context
  -> draft_external_email
  -> send_email

Search may be authorized and sending may be authorized, while sending those records to that recipient is not. Check the combined operation and the destination. The same problem appears when a webpage supplies a command, a tool response changes the next target, or a stored memory influences a later write.

Tool output remains data from its source. It cannot grant new authority. Enforce policy again at the next execution boundary, even when the preceding tool succeeded.

Inspect authority outside the tool description

A local server inherits process privileges. A shell command may reach files, network services or environment credentials absent from the advertised tool list. A cloud role may allow an alternate API that bypasses the application's checks.

Review the actual token scopes, resource policy, network reach and process permissions. Keep credentials out of model context and ordinary logs. For MCP, pin the protocol and transport before applying version-specific advice about authorization or sessions; the MCP review checklist separates current request handling from legacy behavior.

Keep a record that supports a retest

Record the user and tenant, workflow and tool identifiers, allowed parameter fields, target, policy result, approval reference and downstream outcome. Correlate these with source references and a trace ID. Restrict log access and retention; do not copy credentials, authorization headers or unrestricted message bodies into a second data store.

The review output can be one maintained tool register linked to the relevant tests and findings. Separate deliverable tables for actions, credentials and chains add little if nobody can tell which test covers a tool after it changes.

Test the neighboring operation that must fail

If the agent can draft a reply, try sending it without the required approval. If it can update one ticket, try another tenant's ticket. If it can deploy to preview, select production with the same credential. Confirm the authorized operation still works.

Then change state between proposal and execution: revoke access, edit the target or let the approval expire. Disable the tool while work is queued. Those checks reveal whether the permission survives contact with the runtime, rather than merely appearing in a configuration file.

The secure tool-access implementation guide includes a runnable document-policy example and parameter-bound approval checks.

AI Agent Tool Permissions: Read, Write, Delete, Send, Execute, Deploy