Tools are permissions

What you will learn Four things to check before attaching a tool, and how organisations divide permissions.

A change of perspective

So far we have seen tools as "more things it can do." From a security perspective the same fact looks like this:

Attaching a tool is granting the agent a permission.

Attach a delete_file tool and the agent has permission to delete files. When that permission gets used is up to the model's judgement.

Four questions before attaching

1. How far does this server reach?

text

"We attached the GitHub MCP server"→ which repositories are visible? All? One organisation?→ are private repositories included?→ is it read-only, or can it write?

Usually the answer is the permission on the token you issued when attaching it. Grant a narrow token and the server's reach narrows with it.

Least privilege: grant only what is needed now and widen later if necessary. Granting wide and narrowing later rarely happens.

2. Are there irreversible actions?

The most important distinction.

Character	Example	Response
Read	lookup, search, calculate	generally safe
Reversible write	create a temp file, save a draft	logging is enough
Irreversible	send email, payment, delete, publish externally, `db_update`/`db_delete`	human approval

"You cannot unsend an email." That one line is the criterion for where approval goes.

3. Can human approval be inserted into that action?

As we saw in tool use, the system executes. The model only requests. So approval can go in between.

graph TD
  A["Model: requests send_email"] --> B{"Irreversible action?"}
  B -->|"no"| C["Execute immediately"]
  B -->|"yes"| D["Ask a person to confirm"]
  D -->|"approve"| C
  D -->|"reject"| E["Do not execute"]

If your system has no approval point, the right call is not to attach irreversible tools at all.

4. Where do the credentials live?

text

✗ API key written in the prompt      → ends up in the conversation log✗ hardcoded in the source            → ends up in the repository✓ environment variables · a secret manager → separated

And decide in advance what to do if a key leaks. Usually "issue a new one and revoke the old," but someone has to know that procedure.

Dividing permissions in an organisation

Not everyone in a workspace needs the same tools.

Split by	Example
Team	sales gets CRM tools, engineering gets repository tools
Role	only admins get write tools, everyone else read-only
Environment	production system tools only in a specific workspace

That is why Connect lets you enable tools per workspace and separate member roles.

Grant permissions to groups, not to people. Start adjusting per individual and eventually nobody can describe the current state.

Scenarios to watch

Attaching someone else's MCP server

Convenient, but you have to check what that server does. Is it from an official provider, and what permissions does it ask for? Especially so if it touches internal data.

And there is one more thing. You do not write the tool list — the server announces it. On connection the server sends "here are my tools and here is what each one does", and the model reads those descriptions to decide what to call. In other words a tool description is an instruction aimed at the model — the same property as when what it reads becomes a command.

The conclusion is an uncomfortable one.

If the server changes its tool descriptions, behaviour changes on your side without you changing anything.

The server you reviewed on the day you attached it can announce different tools next month from the same address. Your configuration is one line — an address — so nothing looks different.

Write down these five before you attach it.

text

□ Who built it — the official provider, or a third-party wrapper?□ Where does it run — inside your network, or out to someone else's server?□ What does it ask for — the scope of the credential it wants□ Would you notice a change — any way to tell the tool list changed?□ Can you turn it off — a procedure to disable this one server if it misbehaves

The fourth is usually blank. At minimum, record the tool list (names and descriptions) as it stood when you attached it, and compare it against the current one at your quarterly review — the step 1 table in try auditing tool permissions is that place.

At an organisational level, keeping a list of servers that may be attached is the simplest control there is. Once everyone attaches a new server whenever they need one, nobody knows what is attached.

When an agent combines tools

Each tool is safe but the combination is dangerous.

text

read_file (safe)  +  send_email (approval required)→ creates a path that reads internal documents and sends them outside

So approval belongs on "irreversible actions," not on individual tools. With approval on send_email, this combination is blocked too.

Common misconceptions

"Are all read tools safe?"

It depends on what they read. A tool that reads HR records or customer personal data is sensitive even though it only reads. "Is it reversible?" and "should this be seen?" are different questions.

"For security, is it better not to attach tools?"

Then hallucination rises and answers lose their basis. The practical order is read tools first, write tools with approval. Attaching nothing is not the safe choice.

Check yourself

1. What one-line criterion decides where approval goes?

Answer

"Is it reversible?" A sent email, an executed payment, and deleted data cannot be undone, so a person goes in front of them.

2. Give an example where each tool is safe but the combination is not.

Answer

read_file + send_email creates a path that reads internal documents and sends them outside. That is why approval belongs on "irreversible actions" rather than on individual tools.

3. What does least privilege mean applied to tools?

Answer

Granting only the permission you need now when you create the token. Granting wide and narrowing later rarely actually happens, so start narrow and widen when required.

Now apply it to your own workspace — a 30-minute audit → Audit your tool permissions