What access should you give an AI agent?
Permissions, approvals, personal data and prompt injection: questions to resolve before connecting working systems.
An agent connected to a CRM, email or documents can change business data as well as answer questions. Grant access for a specific task. An instruction to “be careful” does not replace technical restrictions.
Start with minimal permissions, separate integration accounts and approval for important actions. Enforce boundaries through tools and data access.
Separate reading from writing
An order-status assistant may only need read access. A writing assistant can create a draft without permission to send it. These boundaries are easier to verify than full access accompanied by a request to avoid dangerous features.
Use a separate integration account restricted to relevant records and operations. A staff member's shared administrator password makes monitoring and revocation difficult.
Understand prompt injection
Prompt injection attempts to influence model behaviour through untrusted messages, documents or web content. A file might instruct the model to forward internal data to an unrelated address.
Process external text as data rather than authorisation. Validate tool arguments, allowed recipients and permissions independently of the model. Filters and instructions do not provide absolute protection.
When approval helps
Human approval is useful for external messages, deleting records, financial changes and other consequential actions. Staff need to see exactly what will happen, which data is involved and who will receive it.
An approval button without those details does not provide meaningful oversight. Use a safe draft mode during the initial pilot where possible.
Handle information deliberately
Determine what the model needs and where it is processed. Keep secrets out of instructions and logs. Limit personal-data copying and agree on retention for the jurisdiction and process.
Review provider terms, access and deletion settings. Using a well-known model or cloud service does not automatically satisfy every requirement a customer may have.
Prepare for launch and shutdown
Check that access can be revoked, keys replaced and the process stopped promptly. Action history should show who changed what. Prepare a manual workflow for when the agent is disabled.
Test suspicious documents and requests that exceed the task. Improve permissions and tool validation as well as the instruction text.
A support agent's permission matrix
List resource, allowed action, permitted records and approval requirement. Reading a service description does not require access to all CRM data or payments.
An illustrative policy permits approved reading and drafting, requires initial approval for sending, and forbids deletion. Enforce permissions in tools and connected systems, not just instructions. Use a separate service account and bounded tools. Access can then be revoked without disabling the whole team, and agent actions are easier to identify.
A document must not grant authority
External messages may ask the agent to expose data or ignore rules. Treat them as data, not permission to act. Restrict capabilities outside the model itself.
Separate retrieved content from instructions, validate calls and block arbitrary access. Test provocative documents and inspect attempted actions as well as answers. Observe behaviour after deployment. Layered controls reduce risk; one safe response does not prove resistance to every future message.
Agree data handling
Identify what each service receives, storage location, access and retention. Send only the permitted data needed; logs and alerts can also reveal sensitive information.
Apply user permissions before retrieval and actions. Do not provide internal documents and simply hope the agent will avoid quoting them. Requirements depend on countries, contracts and information types. Assess the actual project rather than claiming universal compliance because an agent has been installed.
Prepare incident handling
Provide a stop control, credential revocation and human fallback. Name who acts and which connected components to disable first.
Keep sufficient history under controlled access. After repair, check erroneous updates, duplicate messages and excessive permissions before restoring operation. Test prohibited actions as carefully as useful functions. The business should retain control over consequential decisions within the agreed implementation.
What to check
- Give the integration separate, minimal permissions.
- Separate drafting, approval and execution.
- Validate untrusted input and tool arguments.
- Prepare access revocation, action logs and manual handling.
Sources and documentation
Have a business task in mind?
Tell us what you need. We'll suggest where to start and how to check the result later.
Discuss your projectFree · 30 minutesExplore the service
