An assistant that queries your compliance data over MCP is an account. Here is what the MCP authorization spec guarantees, what a read-only boundary does and does not protect, and the account-management questions to answer before you connect one.
An assistant that queries your compliance data over MCP is an account. Here is what the MCP authorization spec guarantees, what a read-only boundary does and does not protect, and the account-management questions to answer before you connect one.
The Model Context Protocol lets a server attach hints to each of its tools, and one of them, as the schema puts it, means "the tool does not modify its environment." The tools section of the specification then tells every client what that hint is worth: "clients MUST consider tool annotations to be untrusted unless they come from trusted servers." The authorization section opens with a sentence that matters just as much: "Authorization is OPTIONAL for MCP implementations."
Together they mean that a vendor's statement that its MCP server is read-only describes the server without constraining anything. The control is what the server enforces and what the grant allows, and whether either exists depends on the server you connect.
This matters to compliance teams because the data these servers expose is the ISMS itself: risks, open audit findings, vendor assessments, the list of controls you haven't covered yet. Connecting an AI client to that data is an access decision. It deserves the same questions as any other one.
You don't need a new framework to govern an AI client. Access-control catalogs already cover it. I quote NIST SP 800-53 here because its text is free to read; the access-rights controls in ISO/IEC 27001 Annex A ask the same questions.
NIST SP 800-53 Rev. 5, AC-6 Least Privilege:
"Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks."
An MCP client is a process acting on behalf of a user, so the control applies to it as written. The rest of the lifecycle comes from AC-2 Account Management, which requires the organization to:
Two enhancements sharpen it. AC-2(3) says to disable accounts that, under item (d), "Have been inactive for [time period]". AC-6(7) asks you to "Review [frequency] the privileges assigned to [roles and classes] to validate the need for such privileges".
Read against an AI client, those clauses become four questions:
If you can't answer one of these for a connected assistant today, the unanswered question is the gap to close.
When a server does implement authorization, the specification is precise about it. The server "acts as an OAuth 2.1 resource server". The client runs an OAuth flow against an authorization server the MCP server points it to. The clauses that carry the most weight for an access review are these.
Audience binding. "MCP clients MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707", and "MCP servers MUST validate that access tokens were issued specifically for them as the intended audience". A token issued for your compliance tool can't be replayed against another service, and the server "MUST NOT accept or transit any other tokens."
Code interception. From the security considerations: "MCP clients MUST implement PKCE". A stolen authorization code is useless without the verifier the client kept.
Token lifetime. "Authorization servers SHOULD issue short-lived access tokens to reduce the impact of leaked tokens. For public clients, authorization servers MUST rotate refresh tokens". The same section names why: "Attackers who obtain tokens stored by the client, or tokens cached or logged on the server can access protected resources with requests that appear legitimate to resource servers."
Scope. Servers "SHOULD include a scope parameter in the WWW-Authenticate header", which the specification frames as "following the principle of least privilege and preventing clients from requesting excessive permissions." A request that needs more gets a 403 with error="insufficient_scope", and a client acting for a user is expected to send the user back through authorization for the wider grant.
Mapped onto the four questions:
| Access question | What the MCP spec gives you | What stays with you |
|---|---|---|
| Who approved it? | A user-facing OAuth authorization step | Whether the approver was the right person |
| What can it reach? | Scopes, audience-bound tokens | Which scopes the server defines and grants |
| When does it stop? | Short-lived tokens (SHOULD), rotating refresh tokens (MUST, public clients) | Revocation on offboarding, inactivity expiry |
| Who reviews it? | Nothing | The periodic access review |
Read the last column first. The specification secures the handshake. It says nothing about offboarding, inactivity, or review, because those are properties of the server's account model, and a protocol can't mandate them. That's where to press a vendor.
A server that only reads protects the integrity of your compliance record. The assistant can't close a finding, lower a risk score, or mark a policy approved. For an ISMS that matters: an auditor reading a change history should never find an entry that a model wrote on the strength of a misread prompt.
Read-only does nothing for confidentiality. Every record the model reads becomes input to the model, which means it goes to whoever runs the model under the terms of your AI client. Your open findings, your risk register, the names on your vendor list all travel with the query. That is a decision about which AI providers you've approved for which data classes, and no server setting makes it for you.
The tools specification puts two further duties on the client, not the server. Clients SHOULD "Show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration", and they SHOULD "Log tool usage for audit purposes". The page also says "there SHOULD always be a human in the loop with the ability to deny tool invocations." Those are client behaviors. If your AI client doesn't show what it's about to call, or keeps no record of what it read, the server can't make up for it.
The alternative to a grant is a static API key pasted into the client's configuration. Held against the four questions, the key and the grant give different answers.
A static key is a long-lived secret stored in a config file on a laptop. Unless the vendor scopes it, it carries the reach of whoever created it, and it stops only when it expires or someone deletes it. Nothing in the key ties it to one client, one tenant, or one purpose. AC-2(3)'s inactivity clause has nothing to act on unless the key happens to expire.
An OAuth grant is a different kind of object. It names a client, it carries the scopes the user consented to, the access token it produces is short-lived, and the refresh that keeps it alive can be cut from the server side. Revoking it is an administrative act with a timestamp, which is what an access review wants to see.
Before connecting any MCP server to data that sits in your ISMS, these are the questions I'd want answered:
We had to answer the same questions for devguard's own MCP server, announced on 9 September 2026, and some of the answers cost something.
The server only reads: an AI client can query and read single records, and it cannot change or delete anything. The server enforces that itself, whatever the hint on each tool says, and each connection sees one organization.
Clients that support the browser sign-in need only the endpoint. In Claude Code:
claude mcp add --transport http devguard https://app.devguard.ch/api/mcp/In VS Code, in .vscode/mcp.json:
{
"servers": {
"devguard": {
"type": "http",
"url": "https://app.devguard.ch/api/mcp/"
}
}
}On first use, the client opens a browser. You sign in as yourself, pick the organization it may read, and the consent screen names that organization before you allow it. Nothing goes into a config file.
The four questions, as the product answers them:
Two things devguard leaves out on purpose, and one cost it accepts.
An AI client can't be granted write permission, not even a narrow scope; the only write permission devguard issues through this sign-in belongs to its own CLI, for uploading evidence. Any MCP client can ask to connect, and an assistant that misreads a prompt should find nothing to change.
devguard does not record each individual read. The audit log shows that an app was connected, by whom, and when it was disconnected; Connected apps shows when it was last used. A per-query record of what the model read lives in your AI client, which is where the MCP specification puts that duty.
The cost: Claude Desktop reaches remote servers through the mcp-remote bridge, and devguard set that connection up with an API token rather than the browser sign-in. That token is exactly the static key described above. At the MCP server it is still read-only, but outside it the token can do everything you can do, in every organization you belong to. If you use Claude Desktop, treat that config file as a secret and give the token an expiry date.
Whichever server you connect, write the AI client into the same register as every other account: who approved it, which organization and scope it holds, what ends it, and when it is next reviewed. If the server can't give you an answer for one of those columns, that is the finding.
devguard's MCP server reads your compliance data and changes nothing; the announcement covers the setup, and Settings → Integrations has a snippet for each client.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.