Model Context Protocol (MCP) Security · Authentication & Authorization
Protect request state from tampering
Verify that MCP servers protect the integrity of `requestState` that influences authorization, resource access, or business logic, and reject state that fails verification.
OWASP AISVS v1.01, requirement 10.2.8
In plain English
Some MCP flows give the client a piece of state (requestState) to send back in a later request. If that state affects authorisation, resource access or business logic, the server must protect it so the client cannot alter it, and must reject anything that fails the check.
What good looks like
- State that influences decisions is signed or encrypted by the server, or kept on the server with only a reference sent out.
- The server verifies the state on its return, before acting on it.
- Tampered, expired or malformed state is rejected.
- The state is bound to the user and the request it was created for.
How teams usually do it
- Sign the state with a server-held key (an HMAC or a signed token), including the user, the purpose and an expiry.
- Or store it server side and send an opaque, unguessable identifier.
- Authenticated encryption where the contents should also be hidden from the client.
Suggested evidence
- Code showing how state is created and verified.
- Tests with altered, expired and swapped state, each rejected.
Common mistakes
- Trusting state because the client was supposed to return it unchanged.
- Signing the state without binding it to a user, so one user's state works for another.
- Encoding (for example Base64) mistaken for protection.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.