Is an MCP server safe? What the NIS2 walkthrough checks on every call

What can an assistant do through the MCP server, and what not?

MCP (Model Context Protocol) is an open standard through which an AI assistant such as Claude or Copilot works with another program. The NIS 2 walkthrough offers an MCP server for it at /api/mcp. A connected assistant reads your walkthrough there and fills in what its items ask for.

It works as the person who connected it, with exactly that person's rights. If certain areas are assigned to them, their assistant fills in only those. The assistant of someone in the reviewer or legal reviewer role reads but fills in nothing.

Signed in through the browser or using a key, an assistant reaches a fixed list of the app's functions, and the app checks this on every call. Nothing on that list deletes a row, invites colleagues, finishes an item or signs. That stays with people, in the app.

What does the server check on every call?

Each call is checked on its own. First the key: its signature, its expiry, whether the person has since disconnected all their assistants, and whether this one connection still stands.

Then the same gates as in the app: membership of the company, role, whether the walkthrough is unlocked for the account, the assigned areas. On top of that comes the switch “Allow AI assistants for this company”, which is off until an admin turns it on.

A call from a browser on an address other than the instance's own or localhost is refused. So a foreign web page cannot reach even an instance inside the company network through someone's browser. Each person has at most 300 tool calls per hour, for all their assistants together.

Every change appears in the activity log under the person's name, with “via” and the assistant's name. The server log gets one line per call with the tool and the person's id, never the content. The code is open source under the AGPL; your IT can read what this page describes in the lib/mcp folder.

How does the sign-in protect against stolen access?

With the browser sign-in, your instance is itself the sign-in service, under OAuth 2.1, the standard for this kind of permission. PKCE (S256) comes on top, so that an intercepted sign-in code is of no use to anyone else.

Before allowing, the page shows which assistant asks for which company and where the browser returns to afterwards. The assistant gives itself its name, so check the return address above all. A faulty request is answered on the instance's own page and sent nowhere.

A refresh token renews a sign-in. If one that was already used turns up again more than a minute later, it counts as copied, and the instance disconnects every assistant of that person.

Key and sign-in outlast signing out of the browser. That is why both ask for a sign-in from the last 15 minutes, and the person gets an email as soon as an assistant was connected in their name. How long each one lasts is in our article on a key or a sign-in.

Does the server meet the MCP specification and OWASP?

The MCP specification, version of 28 July 2026, requires OAuth 2.1 of the sign-in service and PKCE with S256 of clients. For public clients, those without a secret of their own, it requires rotating refresh tokens. Of the server it requires validating inputs, controlling access and rate limiting calls; the walkthrough does this as described above.

One of its recommendations is not met: Client ID Metadata Documents, with which an assistant identifies itself through a published identity. The walkthrough registers assistants automatically (Dynamic Client Registration), which the specification lists as deprecated but still allowed. In Claude you therefore choose “Register automatically”.

OWASP lists excessive agency as risk LLM06: too much functionality, permission and autonomy. Among OWASP's mitigations: a human approves high-impact actions, actions on a person's behalf run with that person's rights, and the downstream system checks authorisation itself. In the walkthrough these are the signature that people give, the person's rights and the check on the server.

What stays with your company?

You choose which assistant to connect. Whoever gets into the account with the assistant's vendor also uses that account's connection to the walkthrough. So record in 11.1 whether signing in there takes a second factor, as for every program on your list.

The MCP specification says there should always be a human in the loop who can deny tool calls. Leave the client's prompt before filling in turned on.

The server limits what an assistant can do and shows what it did. It does not make the assistant error-free; how a text written by others can mislead an assistant is shown in our article on prompt injection.

A key belongs in no file that others read, such as a shared repository. Put it in an environment variable and give the client the variable's name, in Claude Code like this:

Art. 21(2)(j) NIS 2 · § 30(2) No. 10 BSIG

claude mcp add --transport http nisd2 https://nisd2.eu/api/mcp --header "Authorization: Bearer $NISD2_MCP_KEY"