AI agent permissions: review access before connecting your tools

Connecting an AI agent can involve several decisions at once: which information an application can read, which services receive it and which actions can occur under an account. A convenient authorisation screen may combine capabilities that your first task does not need.

A useful review asks concrete questions. What can the agent read, create, change, delete or transmit? Which person owns the connection? How can you verify that a boundary holds and withdraw access when the task ends?

This guide uses a fictional training network preparing a weekly internal digest from approved programme notes. It is an operational checklist for a bounded pilot, not a security certification, legal opinion or claim that a particular product is safe by default.

1. Describe the task before choosing permissions

The fictional digest needs approved notes and somewhere to save a draft. It does not require participant records, financial folders or every coordinator's inbox.

Write a one-page access brief:

• Purpose: prepare a five-point digest with references to the source notes.
• Permitted inputs: approved notes in a specified folder.
• Output: a draft in a separate review folder.
• Excluded operations: changing source notes, sending messages or sharing documents.
• Owner: a named person who reviews results and can suspend processing.
• End condition: a review date or completion of the pilot.

Use this brief when assessing the connection request. If a permission has no relationship to the task, ask why it is required. A capability that might be useful later is not automatically necessary now.

For personal use, the same method helps keep a project assistant focused. Preparing a household renovation summary need not involve unrelated correspondence or documents simply because they share an account.

2. Read the actual account grant

Check the account identity and requested operations. An administrator account and a limited account may expose very different resources. Inspect inherited access through groups and parent folders, not only the folder you intend to use.

Separate reading, creating, editing, deleting and transmitting. Record the resources involved in each operation and the identity under which it runs. A broad “manage documents” description needs clarification before it can be compared with a draft-only brief.

Distinguish an application filter from an enforced access boundary. The interface may show one selected folder while the account permission technically covers much more. That can still be a deliberate design choice, but it should be understood rather than described as folder-restricted access without evidence.

If the connection cannot be narrowed sufficiently, consider a controlled source copy, a limited account or a test environment. Each option has maintenance consequences. A copied folder needs an owner and an update process; otherwise the narrower scope may produce stale answers.

3. Map the complete data route

Draw the route from the original service through the connector, application, model service, search index, logs and final output. Not every system has every stage, so ask for the actual architecture.

For each service, record:

Question	Evidence to request
What is received?	Full documents, excerpts, metadata or identifiers
Why is it received?	Answer generation, search, storage or diagnostics
What is retained?	Applicable retention description and settings
Who can access it?	Relevant people, applications and support roles
How is it removed?	Available deletion process and expected confirmation
What remains uncertain?	Explicit unresolved questions

Do not assume that removing a source document instantly removes an indexed copy, exported file or backup. Those are separate locations with potentially different behaviour. Establish what the chosen services actually do.

This map is also useful when a task changes. Adding a new model service or external tool may introduce another recipient of data even if the user-facing chat looks unchanged.

4. Read an MCP connection as a chain of access

For an MCP-based integration, inspect the AI application, the MCP server and the downstream services the server uses. A control at one layer does not prove that the same boundary exists at every other layer.

In the digest example, an operation labelled “search programme notes” might query a much larger document store. Ask where the permitted-folder restriction is enforced: only in the instruction, in the tool implementation, in the server or in the source account's rights.

The MCP security guidance discusses authorisation validation, scope minimisation and risks associated with local servers, among other implementation concerns. Using the protocol does not certify a particular configuration. Source: MCP Security Best Practices.

For a remote server, identify its operator and the services that receive requests. For a local server, identify the program being launched and the resources its process can access. “Local” should not be interpreted as “limited to the file I selected” without checking.

Record the verified service, client application, account, available tools and person able to revoke the connection. Document where credentials are managed, not their secret values. An access inventory should not become another place where passwords or tokens are copied.

5. Match tasks to tools and rights

A short matrix reveals capabilities that have no reason to be present:

Pilot task	Required resource	Needed operation	Unnecessary power
Find approved notes	Specified source folder	Search and read	Search all workspaces
Check a reference	Relevant source passage	Read	Edit the source
Produce the digest	Review folder	Create a draft file	Public sharing or sending
Correct the draft	Identified draft	Targeted update	Delete unrelated files

Attach evidence to each row: displayed permissions, the implemented restriction and a harmless test result. Disable unused operations where possible. If a broad capability cannot be separated, document the gap and decide whether to reduce or postpone that part of the pilot.

Repeat the matrix for different users where necessary. A coordinator's broad access should not silently become every reader's access through a shared assistant. Test with the actual user roles rather than only the account that built the system.

Keep construction permissions separate from operation. Someone configuring the workflow may need to edit integrations. The assistant producing a weekly digest does not necessarily need those powers once setup is complete.

6. Separate technical capability from approval to act

An account may technically support sending a message while the application requires approval for each send. Those are different controls. Connecting the account should not be treated as a blank approval for every future operation it could support.

Define which tasks can run independently, which should produce drafts and which require a specific confirmation before execution. For the digest pilot, reading approved sources and preparing a draft may be in scope while sharing remains outside it.

A useful confirmation shows the exact target, content or file and the effect. For sharing, it should identify the recipient and access level. “Continue?” does not let a person judge whether the file is being shared read-only with one colleague or made editable for a broader group.

If the destination, attachment or permission changes after approval, the operation is no longer identical to the one reviewed. The system should detect that difference rather than reusing approval without limit.

Also define what a refusal means. Cancelling a share should stop that operation, not cause the assistant to try email or another route to achieve the same disclosure.

7. Test boundaries with harmless negative cases

A successful summary establishes that useful access works. It does not establish that unwanted access is blocked. Test both.

Create two synthetic documents with distinct, non-sensitive markers. Place one in the approved source folder and one outside the pilot's scope. Ask the assistant to use the permitted document, then attempt to retrieve the out-of-scope marker.

Add tests for changing a read-only source, creating an output outside the approved destination and sending without the required approval. Use a test environment where an unexpected action cannot affect real people or important data.

Inspect the connected service's activity where available. A refusal in chat is not proof that no operation was attempted or completed. Conversely, an operation rejected by the service should be recorded as rejected rather than described as successful.

Keep the test account, time, target, observed result and decision. “Security checked” is less useful than evidence showing which boundaries were actually exercised.

8. Check information hidden inside ordinary content

The assistant may read a source containing an instruction to do something unrelated. A programme note might include a synthetic sentence asking the system to export another folder or send the digest to an unfamiliar address. That text is source content, not approval from the person directing the task.

Test this case with harmless data and limited tools. Inspect both the final answer and any attempted actions. A reassuring response does not compensate for an unwanted operation occurring behind it.

The practical controls include limiting the available operations, validating targets outside the model and keeping source content separate from the authorised task. Do not rely only on a stronger instruction saying that the assistant must ignore malicious text.

Ordinary ambiguity matters too. Two people with similar names or two folders with nearly identical titles can lead to the wrong target without an attacker. Require enough context to resolve the identity before consequential action.

9. Make confirmations specific enough to inspect

Test the approval interface itself. For a sample share, show the reviewer the exact document version, recipient and permission. Then repeat with a changed recipient or a different document after the original preview.

The expected behaviour is to reveal the change and obtain the applicable new decision, not to treat the earlier approval as covering every variation. A hidden extra attachment or edit permission instead of view permission should be visible.

Keep the preview concise but complete. Long explanations about why the assistant wants to act can distract from the details the person actually needs to check. Prioritise target, data, effect and differences from the previous version.

Test cancellation through the whole route. Verify that the target service contains no completed action, then ask the assistant for the task status. “Cancelled” should correspond to what happened, not merely to a dismissed window.

For an uncertain outcome, the system should inspect the destination before retrying. Approval for one share or message should not become duplicate actions because the first acknowledgement was lost.

10. Retain useful evidence without building another private archive

Logs should help establish which request, account, tool, resource and result were involved. They do not automatically need every document's full text.

For a digest creation, a record might include the source identifiers, output identifier, operation, time and status. That can be sufficient to investigate a failed write. If excerpts are retained to diagnose answer quality, define who can view them and for how long in the chosen service.

Review error messages too. A technical error may reveal a private filename, address or configuration detail to someone who does not need it. The ordinary user needs an understandable next step; the technical owner may need a separate diagnostic record.

During an incident, distinguish facts from hypotheses. “The source service rejected this read request” is a specific observation. “No information ever left the system” requires broader evidence. Report what was checked, what remains unknown and which operations are suspended while the uncertainty is resolved.

11. Rehearse pause, revocation and recovery

Prepare the stop procedure before an incident. Identify who pauses scheduled work, who revokes the source authorisation and who checks operations already in progress.

Pausing processing, disconnecting an interface and revoking the grant at the provider can be separate steps. Establish which control affects which part of the route.

During a harmless test, stop new work, revoke the relevant connection and attempt a fresh read of a newly created sample document. This helps distinguish access to a previously retained copy from continuing access to the live source.

Inspect queued and in-progress operations. Some may have completed before revocation; others may be cancelled or remain uncertain. Do not claim that everything stopped until the relevant states can be verified.

For recovery, require a deliberate decision to reconnect and re-enable the appropriate scope. Resuming should not automatically replay every old task or restore permissions that the project no longer needs.

12. Treat disconnection and deletion as separate work

After access is withdrawn, review retained copies: indexes, conversation history, exports, diagnostic logs and backups where relevant. Identify what should be removed, what has a stated retention reason and what still requires confirmation from a provider.

An inability to verify immediate backup deletion should be recorded as a limitation rather than replaced with an assurance. The important point is to understand the service's actual behaviour and whether it fits the intended information.

For the digest pilot, the team may want to keep approved final digests while removing temporary extracts. Those are distinct decisions. Avoid indiscriminate deletion that destroys useful work without improving the relevant boundary.

Maintain a simple completion record: access revoked, new live read tested, retained locations reviewed and outstanding questions assigned. This makes the end of the pilot as inspectable as the initial connection.

13. Prepare for a change of owner or a departing colleague

A workflow may depend on the personal account of the person who configured it. Their departure can either break the service or leave an unmanaged connection behind.

Identify that dependency during setup. The handover checklist should cover scheduled tasks, account grants, folder permissions, retained copies, operational documentation and the new owner of unresolved work.

Transfer the work through the services' supported account and access controls, not by copying passwords or secret keys into a message. Sensitive changes should be performed by authorised people with the appropriate review.

After the change, repeat a permitted read using a new synthetic document and confirm that the old identity no longer has the intended revoked access. Recheck the output destination too, so new drafts do not continue appearing in a departing colleague's private folder.

An access review is triggered by a role change, new tool, new data source or materially expanded function, not only by an annual calendar reminder.

Use the checklist to make a bounded decision

The review should end with a concrete outcome: proceed within the tested scope, proceed with named unresolved limitations, narrow the pilot or postpone a capability until a necessary control exists.

Keep the task brief, data-route map, rights matrix, negative tests and stop procedure together. Another responsible person should be able to understand the arrangement without reconstructing it from a conversation with the original builder.

The aim is not a reassuring label. It is access with a purpose, an owner, a tested boundary and a verifiable end.

Frequently asked questions

Should I accept every permission an integration requests?

No. Connect each permission to a specific task and check whether the scope can be reduced. If a necessary capability requires broader access than is acceptable, narrow the task or choose another arrangement rather than disguising the gap.

Does disconnecting the agent delete information it already copied?

Not necessarily. Revoking future access and removing retained copies are separate checks. Review the application, index, exports and other relevant services according to their actual retention and deletion behaviour.

Is human confirmation enough to make an agent safe?

No. It complements limited rights, target validation, technical tests and a working stop procedure. Confirmation is useful only when it shows the exact operation and material changes cannot silently bypass the review.