How to study for the MCPA security and governance domain
Security and governance is 24% of the new Model Context Protocol Associate exam. Here is what each competency actually covers in the 2026-07-28 spec, and the distinctions candidates get wrong.
The Agentic AI Foundation and Linux Foundation Education launched the Model Context Protocol Associate (MCPA) on September 14, 2026. It is the first official certification for MCP, it is vendor neutral, and it is built against the 2026-07-28 specification.
Look at how the exam is weighted and one thing stands out:
Security and governance is the second heaviest domain. Almost a quarter of a foundational protocol exam is about trust boundaries, permissions, consent, and audit, and the listed prerequisites include OAuth 2.1 and token handling. That is a fair signal about where the difficulty in production MCP actually lives.
The official blueprint breaks the domain into four competencies. Here is what each one covers, plus the distinction that trips people up.
Trust boundaries
A trust boundary is any point where data or instructions cross from one party's control into another's. In MCP there are more of these than people expect: between the user and the host application, between the host and the client, between the client and the server, and between the server and whatever upstream API it wraps.
The rule that matters most is that a token issued for one boundary is not valid at the next one. Access tokens are audience bound to a single MCP server, the server validates that a token was issued for it, and the server must not forward the token it received to an upstream API. Forwarding is catalogued in the spec as an anti pattern, not a shortcut, because it launders the audience and destroys any ability to say which party actually acted.
When the server needs to call an upstream API, it exchanges for a new credential of its own rather than replaying the client's.
Commonly missed: candidates treat "the token is valid" as the security question. The exam cares whether the token was issued for this server. A structurally valid token with the wrong audience must be rejected.
Permissions and consent
The thing to internalize is that consent and authorization happen at different times, and the gap between them is the whole problem.
A user approves a scope set once, at connection time, on a consent screen, for a category of actions. The agent then discovers tools dynamically and decides which to call, possibly hours later, possibly ones the user never pictured when they clicked approve. So "access to the MCP server" is not a useful permission. Scopes have to be per tool, and the permission check has to run at invocation, not just at connection.
Two related ideas worth knowing cold:
- Least privilege for agents. An agent's effective permissions should be the intersection of its own grant and the authority of whoever delegated to it. An agent should not inherit an admin's full rights just because an admin installed it.
- Delegation is explicit. On behalf of flows name both parties, the human subject and the acting agent, so the delegation chain survives every hop.
Commonly missed: scope step up and authentication step up are different operations. Asking for more scope is not the same as re-verifying who the user is, and conflating them is a real vulnerability rather than a wording quibble.
Risk and safety controls
This competency covers what constrains an agent once it is already authorized: human in the loop approval, time limits, and the difference between advice and enforcement.
The single most important distinction here is that tool annotations are hints, not security controls. Annotations describe intent, whether a tool is read only, destructive, or idempotent, so a host can decide how to present it. They are declared by the server and are not verified by anything. A client that skips a confirmation because a tool claimed to be read only has trusted an unenforced assertion. Annotations belong in the user experience layer; enforcement belongs in the authorization layer.
Session scoped authorization is the other pattern to know: access that is time boxed to a task, that ends when the task ends, and that the agent cannot renew on its own.
Commonly missed: the STDIO carve out. Implementations using a STDIO transport should not follow the authorization specification at all, and should instead take credentials from the environment. The OAuth machinery is for remote servers over HTTP. Expect at least one question that hinges on knowing authorization requirements are transport dependent.
Auditability and observability
The 2026-07-28 revision made the protocol core stateless. There is no initialize handshake and no protocol level session, so a remote MCP server is an ordinary HTTP workload that can sit behind a round robin load balancer. That is good for scaling, and it means identity has to travel with every request rather than being established once and remembered.
For audit, the question to be able to answer is simple: after an agent acts, who appears in the destination system's log? If it is the human whose token got borrowed, the deployment has an attribution problem no amount of logging volume will fix. If it is the agent, with the authorizing human recorded alongside it, the chain is intact.
Commonly missed: logging that an action happened is not auditability. Auditability is being able to reconstruct which agent acted, under whose authority, with what scope, and whether a human approved it.
Do not skip the OAuth prerequisite
The prerequisites list "basic literacy in security concepts (API keys, OAuth 2.1 and token handling, authentication headers)," which undersells it. The authorization model in 2026-07-28 leans on a specific stack: OAuth 2.1 with PKCE, protected resource metadata for discovery, and resource indicators for audience binding.
One change worth knowing because it is recent: Dynamic Client Registration is now formally deprecated in favor of Client ID Metadata Documents. DCR still works for backward compatibility and will be removed in a future revision. A question written against the current spec may well present DCR as the outdated option.
Exam logistics
Attendees of AGNTCon and MCPCon events can enroll at a 20% discount.
What to read
Read the 2026-07-28 specification directly, and the authorization section twice. It is the exam's stated source of truth, and it is short enough to work through in an afternoon.
For the security domain specifically, the concepts above map onto patterns you can read about in more depth: MCP authorization in five OAuth specs for the standards stack, per-tool scopes, consent, and least privilege for the permissions model, scope step up versus authentication step up for the distinction above, and the security risks specific to MCP servers for the threat model.
Passing the exam and shipping a server that survives an audit are different achievements. If you are doing the second one, AuthKit handles MCP authorization with CIMD registration, audience bound tokens, and on behalf of exchange, so the parts the exam spends 24% of its questions on are configuration rather than code you maintain.
Sources
- Model Context Protocol Associate (MCPA) certification page, Linux Foundation Education
- Just launched: Model Context Protocol Associate (MCPA) certification
- Agentic AI Foundation launches MCPA certification to validate MCP expertise
- Introducing the MCPA, Agentic AI Foundation
- The 2026-07-28 specification, Model Context Protocol blog