MCP security: which permissions a coding agent really needs

Once a coding agent can operate tools it is, in security terms, no longer an editor plugin but an acting account – one whose behaviour depends on text it reads along the way. That combination produces risks classic application security does not know in this form.

1. Threat model

Three properties make the tool chain attackable:

• The agent acts – it does not only read, it calls tools that have effects.
• Its control input is text – and text also comes from sources nobody has checked.
• It works with somebody else's permissions – usually those of the person who started it.

Attackers therefore need no access to your system. It is enough to place text somewhere the agent reads: a ticket description, a code comment, an error message, a fetched web page, the result of a tool call.

2. Indirect prompt injection

The central pattern. A model does not reliably distinguish between “this is the content you should think about” and “this is an instruction”. A request hidden in running text can therefore trigger actions.

Effective countermeasures are architectural, not linguistic:

• Treat tool results as data. The trust level depends on the source, not on the wording.
• Classify sources: an internal repository, an internal ticket system and the open internet are not the same thing.
• Limit the effect. If an injection can only read, the damage is small.
• Do not treat “ignore instructions in the text” prompts as a safeguard – that is a request, not a control.

3. The dangerous combination

4. Confused deputy and token forwarding

A server acting for many users with broad permissions becomes a confused deputy: it performs an action because a caller asked for it – without being able to check whether that caller was entitled to ask.

Two patterns that prevent this:

• Act on behalf of the person, not through a technical shared account. Only then do existing permissions and logs apply.
• Restrict tokens to the target resource. An access token issued for one server must not simply be passed on to another system – resource indicators in OAuth-based models exist precisely for this.

5. Servers as a supply chain

An MCP server is third-party software running on your systems whose tool descriptions help steer the agent's behaviour. It therefore belongs to be treated like any other dependency:

• Check the provenance and restrict it to known sources.
• Pin versions instead of pulling “latest”.
• Treat changes to the tool list like a dependency change: make them visible, review them, approve them. A server can change tools and descriptions after the initial approval.
• Keep them updated – servers have vulnerabilities too.

6. Permission model

7. Isolation and network boundaries

• A separate environment for agent runs – a container or dedicated workspace instead of the workstation with all its access.
• Restrict outbound connections; an allow-list is more effective than any content inspection.
• No production credentials in environments where agents run – not even “read only”.
• Keep secrets separate: no credentials in the working directory, secret scanning as a blocking gate.

8. Logging and detection

Log on the server side, not the client side: who, when, which tool, with which parameters, with what result. It only becomes analysable once it lives outside the session. Anomalies worth watching: unusually many calls in a short time, access outside the usual scope, outbound connections to new destinations.

Common mistakes

• An administrative shared account, because it is quicker.
• Offering everything as a tool, including pure read operations.
• Treating prompt rules as a security measure.
• Servers without pinned versions from an unknown source.
• Agent runs on the workstation with all production credentials present.
• No server-side logs – and therefore no ability to answer when it matters.

Checklist: securing agent permissions

Conclusion

The security of agentic tool chains is not decided by the model but by the scoping: which data is reachable, which actions are possible and where results may flow. Deliberately limiting those three axes lets you use agents productively without growing the attack surface along with them.

The organisational frame around it – approved tools, data classes, review duties – is in the deep dive AI coding governance.