Module 7 · Connect and automate
Tools, connectors and their permissions
In short
When using a tool, the model only asks; the app carries it out with the permissions you gave. Grant permissions as narrow as the task, require confirmation before actions, and revoke unused connectors.
After this lesson you can
- Explain what happens when AI uses a tool, a connector or MCP
- Grant permissions as narrow as the task
- Revoke connectors and permissions that are no longer used
Terms in this lesson
Understand
Tool use is how a model "does something" beyond writing text. The order is always the same:
- You ask for something, say "find my meetings next week".
- The model reads the list of tools the app provides and writes a request: "call the calendar tool, date range such and such".
- The app carries out that request, using the access you have granted.
- The result, say a list of meetings, goes back to the model as text.
- The model reads the result and answers, or asks for the next tool.
When a model may call tools many times and decide the next step itself, we call it an AI agent. The longer the chain of steps, the more its limits matter.
A connector is a link between an AI app and another service you use: e-mail, calendar, file storage, a ticketing system. MCP (Model Context Protocol) is an open standard for building such links, like one kind of plug that fits many devices. An MCP server provides a set of tools; an AI app that supports MCP can use them. The standard makes things easier, but it does not make a server safe by default; that is covered in the lesson on connector risk and prompt injection.
The most important point in the order above: the model holds no rights of its own. Everything a tool does is done with your permissions. If a connector has write access to your whole drive, one wrong tool request, whether because the model misunderstood or because it was misled by outside text, can move or delete anything on that drive.
Narrow permissions are the most reliable fence you have. For each connector, ask four things:
- Read or write? To summarise, read access is enough. Write access only when the task really changes something.
- How wide? One folder, not the whole drive. One calendar, not all. One project inbox, not your personal e-mail.
- With confirmation? Actions that send, delete, pay or change other people's data must wait for you to press approve, every time.
- Test data or real data? When trying a new connector or flow, use a test folder or account first.
Permissions also last. A connector you installed for a project three months ago still holds access today unless you revoke it. Schedule a review: open the list of connected apps in your e-mail and storage accounts, and revoke what you no longer use.
One more habit helps a lot: keep the place where you try things separate from the place where you work. When trying a new connector or flow, link it to a test folder holding copies of unimportant files, or to a test account, not your main inbox or the team drive. If the flow misunderstands and moves every file, the loss is a few minutes to rebuild the test folder. Only once the flow has proven to work as you want over a few tries, link it to real data, still with the narrowest permission. Note which connectors you installed, what for, with what permission and when, in one place that is easy to find; that note is what you open when reviewing and revoking permissions every three months.
Before
The prompt
Tidy up all the files in my drive. Move them into the right folders and delete duplicates. (Storage connector: write access to the whole drive, no confirmation.)
What came back
Done. I moved 1,240 files into 18 new folders and deleted 312 duplicate files, including several versions of "Report_final" with similar names.
After
The prompt
I want to tidy only the folder "Procurement Archive 2025". Do not move or delete anything yet. (Storage connector: read access to that folder only.) Make a proposal as a table: file name, the destination folder you propose, and why. For files that look like duplicates, mark them "possible duplicate" and state the difference (date, size). I will decide and move them myself.
What came back
Proposal for 46 files in "Procurement Archive 2025": File | Proposed folder | Reason PO_vendor_March.pdf | Purchase orders | PO name and content Report_final.docx | Reports | - Report_final(1).docx | Reports, possible duplicate | Dates 3 days apart, sizes differ: may be a revision, not a duplicate ...
What changed
- The first version deleted "duplicates" that may well be important revisions, and you could not review first.
- A one-folder limit and read-only permission make the result a proposal. You still carry out the actions.
- If the proposal is good, you can grant temporary write access to that folder only, then revoke it.
Common mistake
- Mistake
- Giving a connector full access to the whole account "for convenience, so there is nothing more to set".
- Why it hurts
- Small mistakes become big damage. One misunderstanding, one piece of outside text that misleads the model, or one faulty connector reaches all your files, all your e-mail and all your contacts at once. In this lesson's case, overly broad permission let a test empty a database that was not its own.
- Do this instead
- Start from the narrowest permission that still gets the task done. Widen only when needed, for a limited time, and note what you granted so it is easy to revoke.
Try
You want AI to summarise project meeting minutes stored in one shared folder. Which permission fits best?
Sorting card
Which tool actions must wait for your approval every time?
Creating a reply draft that is not sent
Searching files by name in one folder
Reading next week's meeting schedule
Sending an e-mail to a client
Approving an invoice payment
Deleting files from a shared folder
6 cards left
Take home
Every time you install a connector
- I know which tools it provides and what it can change
- Read access when enough; write access only when the task changes something
- Only the folder, calendar or inbox needed
- Send, delete and pay always wait for my approval
- I revoke unused connectors every three months
What went wrong for us
An agent's test run that wiped a developer database
- Context
- We asked an AI agent to review a change and run its integration tests.
- What happened
- The tests set up their database by wiping it. The database address was not set, so the tests used the local development database and emptied it.
- Impact
- Local development data was lost. Restoring it was left to its owner. No production data was touched.
- Root cause
- The tests fell back to a default address when the variable was empty, and the agent was allowed to run any command on that machine.
- What we did
- We stopped running those tests on that machine, reported the data loss to its owner, and reran the tests in a throwaway container.
- The guard we keep now
- Integration tests run only in a throwaway container on its own port, with the address set explicitly. Agent instructions name the ports that are off limits.
The lessonAn agent's permissions should be as narrow as its task, and dangerous defaults should be removed.
What it means for your workWhen giving AI access to files or systems, keep it as narrow as the task and try it first on a copy, not on data people use.