Field report · Deep dive
A field report from VamiGRC
A secure MCP server keeps every decision that matters outside the AI agent. Building the MCP server that connects AI assistants such as Claude to VamiGRC, we learned that a confirmation inside the chat is not a security control: a manipulated agent can answer it itself. This report shows how we moved identity, approvals, autonomy and tenant boundaries into the backend, how we tested each of them, and where the limits still are.
Since the June 2025 revision of the MCP specification, a protected MCP server is an OAuth 2.1 resource server. Practice lags behind, and a GRC platform raises the stakes.
8.5%
of more than 5,200 open-source MCP servers examined in October 2025 used OAuth.
State of MCP Server Security 2025: Research Report (October 2025) (opens external website)
Specification, Revision 2025-06-18: Authorization (June 2025) (opens external website)
The agent reads risks, incidents and supplier data, and it can change them. A wrong change is not only a bug: it can falsify the evidence an auditor relies on.
How can an AI agent work with compliance data without becoming the weakest point of the platform?
We modeled three attackers, using STRIDE for the class of flaw and the OWASP MCP Top 10 as the risk catalog. Select an attacker to see which controls limit them, which negative tests relate to them and what remains.
What remains: In a hijacked session, the agent can still confirm at L2 in the chat, and it can type the delete reference itself. That is why deletes and decisions require approval in the application. Prompt injection itself cannot be fully prevented.
What remains: Whatever the public API and the organisation's limits allow remains possible: a hijacked session can still confirm changes other than deletes and decisions at L2 in the chat, and rollback is only partial.
The common thread: a manipulated agent does not break in. It uses permissions it legitimately holds. Every control therefore has to sit where the agent cannot reach it.
The agent never holds a token the backend accepts as a normal user session. The login chain in four steps:
The assistant discovers the authorization server from the MCP server's protected resource metadata (RFC 9728).
The user signs in to VamiGRC itself and sees a consent screen: which assistant, read or read and change, which tenant.
The assistant receives an access token valid for minutes, not days, bound to the MCP server as its audience, plus a refresh token that changes on every use.
The backend accepts that token only like a contained API token: public API only, never admin functions, and never more than the user's own role.
Our earlier design exchanged the user's login for a backend token at an external identity provider. It worked, but long-lived sessions and token exchange did not mix well, and users saw “login expired” after idle periods. Letting VamiGRC be the authorization server removed that class of problems.
One missing scope, offline_access, made a major AI client fail before it ever showed a login page.
Foundations: RFC 9728: OAuth 2.0 Protected Resource Metadata (April 2025) (opens external website) · RFC 8707: Resource Indicators for OAuth 2.0 (February 2020) (opens external website) · RFC 9700: Best Current Practice for OAuth 2.0 Security (January 2025) (opens external website) · The OAuth 2.1 Authorization Framework (Internet-Draft) (opens external website)
Our first version asked the user to confirm every change in the conversation. It felt safe, but the confirmation was answered inside the same channel the attacker controls.
The control sits in the attacker's channel.
The agent cannot fake these layers. Deletes and decisions also need approval in the app.
Every write is a two-step call. The first returns a preview and stores it on the server, and only its confirmation writes. If the record changed meanwhile, the confirmation is refused.
At the confirm step, the MCP server signs the exact request. The backend rejects a write without it, so a stolen access token used directly against the API cannot write.
A plain “yes” deletes nothing. The user must type the record's reference, and the preview names everything linked to the record. Records that can be archived are archived rather than erased.
Not every action deserves the same trust. Every write route of the public API belongs to an action class, and the organisation sets the highest autonomy level per class, following VamiGRC's levels L0 to L3.
L0
The agent may not act.
In the MCP serverRefused with a clear reason, the person acts in VamiGRC.
L1
The agent prepares, the person acts.
In the MCP serverA draft the person reviews and saves.
L2
The agent acts after a human approves.
In the MCP serverPreview and confirmation, or approval in the app for deletes and decisions.
L3
The agent acts alone, everything is recorded.
In the MCP serverOnly for low-risk classes such as notes.
The organisation sets the maximum, and each person can only narrow it for their own assistants. What applies is always the strictest setting.
Deletes and decisions are never autonomous, and signed decisions such as approvals never go through the chat.
A route without a class counts as blocked. A test fails as soon as a new write route has no class.
Choose an action class, the organisation's maximum and the personal limit. The calculator applies the three rules.
Effective level
L2AI-executed with mandatory approval
Preview and confirmation, or approval in the app for deletes and decisions.
Limited by the organisation's maximum.
Simplified model based on this field report, not a copy of the product configuration.
Consultants work for several clients, so one person often has access to several tenants. The MCP server follows the tenant the person has selected in the VamiGRC app, checked on every call, with no caching. That convenience creates a new risk.
The preview stores its tenant and company, and the answer names them.
The MCP server follows the switch on the next call.
The confirmation is refused before anything is sent.
The server refuses rather than silently falling back to another tenant.
Each test tries to break a control, run end to end against a real backend and a real MCP client, not only in unit tests.
| Check | Expected | Result |
|---|---|---|
| Authorization code used twice | Refused, and the connection it created is ended | Passed |
| Old refresh token reused after rotation | Refused, and the whole connection is ended | Passed |
| Plain “yes” on a delete preview | Nothing deleted, the reference is requested | Passed |
| Tenant switched between preview and confirmation | Confirmation refused, nothing written | Passed |
| Several tenant switches in a row | The connection follows each switch | Passed |
| Delete in another company by id | Not found, the record survives | Passed |
| Write without the confirmation proof | Refused | Passed |
| Person's own limit stricter than the organisation's | The stricter limit applies | Passed |
Testing the controls as an attacker would, not only the features, is what found them.
Five takeaways that carry over to other MCP servers, and five limits, stated openly.
Ten questions from this field report. The more often you answer “yes”, the less your security depends on what the agent does.
Answered: 0/10
The result is an orientation, not audit evidence. Your answers are not transmitted.
This is how we map the controls to the risk catalogs. Both catalogs are young, and the mapping will change with them.
MCP01
OWASP MCP Top 10 (v0.1, Beta) (opens external website)
No token passthrough, short-lived and audience-bound tokens, rotating refresh tokens with reuse detection, access limited to the public API.
MCP10
OWASP MCP Top 10 (v0.1, Beta) (opens external website)
Answers name tenant and company, data from records is marked as untrusted, and the agent only sees what the person's role allows.
LLM06:2025
OWASP Top 10 for LLM Applications 2025 (opens external website)
Autonomy levels per action class, hard caps, and approval in the application for deletes and decisions.
The OWASP MCP Top 10 is a beta, and the Agent Control Standard is at version 0.1.0. All ten MCP risks in our deep dive
The field report prepared for decision-makers: threat model, identity without token passthrough, approvals in the backend, autonomy levels and governance, tenant binding and audit trail, negative tests, questions for vendors and a 30-60-90-day plan.
We review MCP servers and agent integrations the way this report describes: with a threat model, controls outside the agent and negative tests.
Specifications, standards and studies this field report draws on.
Short answers
Because it runs in the same channel an attacker controls. An agent manipulated through prompt injection can answer the question with “yes” itself, and anyone holding a stolen access token bypasses the chat entirely. More effective are controls the agent cannot fake: previews enforced by the server, a confirmation proof bound to the exact request and, for deletes and decisions, approval in the application.
Since the June 2025 revision, a protected MCP server is an OAuth 2.1 resource server. It requires metadata discovery through protected resource metadata (RFC 9728), PKCE, and tokens issued for the MCP server as their audience; token passthrough is prohibited. The field report shows what else is needed as soon as an agent may write.
They define what an agent may do alone: L0 manual, L1 AI-assisted, L2 AI-executed with mandatory approval, L3 fully autonomous and fully audited. In the VamiGRC MCP server, the organisation sets the highest level per action class, each person can only narrow it, and a route without a class is blocked. Deletes and decisions are never autonomous.
No. Text from records is marked as untrusted, but a model can still follow it. The controls limit what a manipulated agent can do, but they do not stop the manipulation itself. That is why deletes and decisions require approval in the application.
With a negative test for every control that tries to break it on purpose: redeem an authorization code twice, reuse an old refresh token, switch tenants between preview and confirmation, write without the confirmation proof, delete by id in another company. End to end against a real backend and a real MCP client, not only in unit tests.
Both are early: the OWASP MCP Top 10 is a beta at version 0.1, and the Agent Control Standard is at version 0.1.0. We map our controls to Token Mismanagement & Secret Exposure, Context Injection & Over-Sharing and Excessive Agency, and will adjust the mapping as the standards mature.
We review MCP servers and agent integrations like an attacker and show which decisions are still within the agent's reach.
