MCP server permissions: what your agent can do

Quick answer

An MCP token should grant granular permissions, not blanket access. In ControlarGastos permissions are split by resource and by operation — gastos:read does not imply gastos:create, and neither implies deudas:write — the check happens before the tool executes, and the token is stored only as a hash. To find out what a given token can really do, call GET /api/mcp/whoami, which returns its effective permissions.

Why this is not a configuration detail

Public conversation about AI agents has moved very fast towards what they can do and very slowly towards what they can break. It is worth facing the problem directly, because it is not hypothetical: the security literature on MCP describes servers granting admin-level access by default, tokens stored insecurely, malicious instructions hidden inside tool descriptions, and agents with several servers connected at once being induced from one to act on another.

The common pattern behind nearly all of it is the same, and it is boringly classic: over-permissioning. Not a cryptographic flaw or an exotic vulnerability, but a credential that could do more than it needed to. When a token can do everything, any mistake — by the model, by the user, or by a third party — becomes a large mistake.

So the right question before connecting an agent to your finances is not "is this server secure?", which is too vague to have an answer, but "what is the very worst thing that can happen with the token I just handed over?".

Granularity: by resource and by operation

A useful permission separates two axes. The resource: expenses, income, groups, tags, debts, budgets, statistics. And the operation: read, create, update, write.

That means you can grant gastos:read without granting gastos:create, and gastos:create without granting gastos:update. There is no master permission that drags the rest along, and none implies another by family resemblance: a token that can read expenses gains nothing over debts, even though debts are computed from expenses.

Which produces the most useful recommendation in this article, and the simplest: always start with a read-only token. An agent that summarises, compares months and answers questions needs no write permission at all. And a read-only token cannot break anything, whether the model gets confused or somebody copies the string. Once the agent has proven it does its job well, grant writes on the specific thing it needs.

Where the permission is checked

This looks like plumbing and decides a great deal. In a well-built server the permission check does not live inside each tool: it lives in the server, and it happens before the tool is invoked.

The difference matters because a check scattered through seventy tools is a check somebody will eventually forget in the seventy-first, and that omission produces no visible symptom. A centralised check in front of all of them holds by construction: a new tool is born protected rather than born needing somebody to remember.

By the same logic, the catalogue the server publishes annotates each tool with the permission it requires. The agent can therefore know in advance that something is off limits, instead of finding out through an error.

What to do with the token itself

Three things that apply to any MCP server, not just this one.

One per agent. It is tempting to create one token and use it everywhere. Do not: if you ever have to revoke it, every integration drops at once and you cannot tell which one misbehaved. One token per agent, named, lets you revoke surgically and see when each was last used.

With an expiry, if the use is temporary. For testing or a seasonal agent, setting an expiry date is free and prevents the forgotten token still alive two years later. Abandoned credentials are an incident classic.

Assume you will see it exactly once. A server that can show you the token again is a server storing it in the clear. Here only a hash is kept, so the application cannot show it to you by design: lose it and you revoke and mint another. It is inconvenient, and it is the correct property.

The two other layers almost nobody looks at

Permissions are the main one, not the only one.

Origin verification guards against an unintuitive attack: a malicious web page open in your browser trying to talk to a server you are authenticated against. The specification recommends checking the Origin header for exactly this reason, and this server checks it on both tool calls and the identity endpoint.

A per-token rate limit covers the rest: an agent in a loop, a retry bug, a badly written integration. Because the limit is per token rather than per account, a runaway agent throttles itself without taking the others down.

Verify, do not trust

None of the sentences above is a guarantee you should believe because you read it here. The way to check is to call the identity endpoint with the token in place:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://controlargastos.es/api/mcp/whoami

It returns the owning user and that token's effective permission list. Effective means what it actually grants today, which can be less than you ticked: some permissions additionally require a usage declaration accepted separately, and until it is, they sit stored while granting nothing. If something you did not mean to grant shows up in that list, you have found it, and still nobody has used it.

Frequently asked questions

What permissions should a read-only agent get?

Only read permissions on the resource it will query. An agent that summarises your month needs to read expenses and perhaps statistics, and nothing else. Starting read-only and widening is always a better order than the reverse.

Can I change a token's permissions after creating it?

Yes, without regenerating it. Permissions are an attribute of the token and are edited from your profile, so removing one takes effect without reconfiguring your client.

Can a lost token be recovered?

No. Only its hash is stored, so nobody can show it to you again. The only way out is to revoke it and create another.

Why does my token grant fewer permissions than I ticked?

Because some require a usage declaration accepted separately. Until then they are stored but grant nothing. Your profile flags it for that specific token, and whoami gives you the effective list.

Is it safe to connect an AI agent to my finances?

It depends entirely on what you let it do. With a read-only token, the worst case is a wrong summary. With an unreviewed write token, the worst case is a great deal worse. The decision is not in the model, it is in the token.

Can I see what an agent has done?

Every token records when it was last used, and the operations it performs remain, like any other operation on your account, reviewable from the application.