Which access to give an AI agent, and which not
This objection comes up earlier than the others, and it is a healthy one. «What could it get up to?» is the right question to ask of any tool you hand the keys to your working systems.
The answer below is not «don't worry». It is a breakdown by type of access: what to open without hesitation, what to open halfway, what never to open, and how to check a product before you press Allow.
The principle to reason from
Formally it is called the principle of least privilege; in practice it sounds simpler: the agent should see exactly what its task requires and not one channel more.
That is not paranoia, it is a way of making the risk something you can hold in your head. If the agent sees one channel and one folder, the question «what can it damage» has a short answer. If you gave it admin, there is no short answer.
A useful check: state the task and see what the smallest access is that covers it. «Sort documents from clients» means a specific folder and a specific chat, not the whole drive and all the correspondence.
What to open without hesitation
Read access to specific places. A channel, a folder, a label in the mailbox, a calendar, a board. Not «email», but «messages labelled Clients». Not «Drive», but «the Projects 2026 folder». Practically every decent integration can narrow the scope — if a product cannot, that is already a signal.
Write access where a mistake is reversible. A draft email, a comment, a task, a card, a row in a spreadsheet with version history. Reversible is the key word here: a draft can be deleted, a sent email cannot.
Housekeeping actions with no recipient. Rename a file to a rule, sort things into folders, apply a label, pull numbers together into a report. None of it is visible to a client.
What to open read-only
Financial systems. Seeing payments, statements, subscription statuses — yes. Initiating a movement of money — no, and it is better for that to be a technical limit than a setting somebody can flip by accident.
Systems holding other people's commitments. A colleague's calendar, the team's tasks. The agent can see that a person is busy and propose something. Moving somebody else's meeting is a decision made for another person, and it gets asked of them.
The code repository. Showing what shipped in a release, which pull request has been sitting four days without review — useful. Writing and merging code is engineers' work and engineers' responsibility.
What never to open
Administration. Managing users, roles, permissions. A tool that can grant itself permissions stops being a limited tool.
Secrets. API keys, tokens, passwords, the contents of a secret store. Separately: a card number does not belong in a chat thread — if one shows up there, the right behaviour from an agent is to refuse and ask that it not happen again, not to «handle it carefully».
Irreversible deletion. Deleting files, emails, records, emptying the bin. A new version next to the old one — yes. Deletion — no.
Private channels. Direct messages, correspondence unrelated to work. In most products that is a limit of the platform itself, and that is a good thing.
Bulk sending without confirmation. A send cannot be recalled. One mistake in the segment and the email has gone to the whole list.
A note on personal data
Restricting access is not enough here — the volume has to be restricted too.
If the task only requires knowing that a document arrived and is legible, the agent does not need the contents of a medical record. If answering a client only requires the order number, it does not need the whole profile.
And a rule that stands on its own: where use requires consent, the absence of consent stops the process. Not «we'll be careful» — we do not do it.
What has to be logged
Access without a log is trust without verification. The minimum worth insisting on:
- what the agent read and when;
- what it changed, with a way to see the previous version;
- what it sent outside and who approved it;
- where it stopped and why.
The last point is underrated and it is the most useful: it shows whether your boundaries are working or the agent is routing around them because you phrased something other than what you meant.
How to revoke
Check this before connecting, not after. The answer should be simple: access is granted through OAuth and revoked on the service's side, in the connected-apps section, in two clicks and without contacting support.
If revoking access takes an email to support, that is not an integration, it is a dependency.
Red flags in any product
The list is short, and it applies to us too — run it against everyone, BossForce included:
- They ask for a password instead of OAuth. A mailbox password handed to a service is access to everything, forever. Decent integrations work through OAuth with limited scopes.
- The scope cannot be narrowed. If the only option is «access to the whole mailbox», you have no choice, which means you have no control.
- No action log. If you cannot see what happened, there is nothing to check.
- Sending without confirmation by default. «Show me first» should be the default state, not a checkbox you have to go and find.
- Asked about boundaries, they answer «the model is trained to be careful». Care is not a limit. A limit is when the action is technically impossible.
Checklist before connecting
- what the smallest access is that covers the task;
- which parts of it can stay read-only;
- which actions are irreversible and whether they have been put behind a confirmation;
- where the personal data sits and whether the agent needs to see it;
- how to view the log;
- how to revoke access in two minutes.
If all six have a clear answer, the security conversation is over — from there it is a matter of configuration, not of trust.