# 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?

```
"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](/guide/ai-tool-use), **the system executes.** The model
only requests. So approval can go in between.

```mermaid
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?

```
✗ 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](/guide/cn-usage) 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](/guide/mcp-prompt-injection).

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.

```
□ 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](/guide/mcp-try-audit) 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.**

```
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](/guide/ai-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?**

<details>
<summary>Answer</summary>

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

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

<details>
<summary>Answer</summary>

`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.
</details>

**3. What does least privilege mean applied to tools?**

<details>
<summary>Answer</summary>

**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.
</details>

---

Now apply it to your own workspace — a 30-minute audit →
[Audit your tool permissions](/guide/mcp-try-audit)