A common mistake is treating tool annotations as enforcement. Annotations describe intent, such as read only or destructive, but they are only hints for the host interface. Enforcement still belongs in authorization logic. Teams also miss that session-scoped authorization should end with the task and not be renewable by the agent on its own.
What teams misunderstand about tool annotations in MCP
Tool annotations are descriptive metadata, not a policy engine. In MCP, they help a host or client present tools more safely, but they do not by themselves stop a model or agent from invoking a dangerous action. The practical mistake is assuming that a label like “read only” changes the underlying authorization boundary.
That matters because annotations are easy to trust visually. A tool can advertise its intent one way while the real control point must still decide whether a request is allowed, for which resource, and under what conditions. For MCP teams, the host interface should treat annotations as guidance for user experience and routing, not as proof of safety.
Security teams should therefore separate “what the tool says it is” from “what the system actually permits.” The enforcement decision belongs in authorization logic, where policy can inspect the requester, the target, the scope, and the context of the session. That separation is the difference between a useful hint and a usable control.
Why session-scoped authorization must end with the task
Session-scoped authorization is useful because it reduces standing access and limits how long a tool or agent can act on behalf of a user. The common failure is letting that approval silently persist after the original task is complete, which turns a narrow delegation into a durable capability. AI Agent Authorisation Guide is a useful companion when teams need a concrete least-privilege model for delegated agent action.
A good session boundary is task-shaped, not identity-shaped. The agent should be able to complete the approved work, but it should not be able to renew the approval on its own, widen scope without fresh consent, or continue using the same authority across later steps that belong to a different intent. When that boundary is vague, “temporary access” becomes standing privilege by another name.
This is especially important when the MCP server or connected tools can touch sensitive business data, destructive functions, or external side effects. The authorization model should be explicit about what ends the session, what requires reapproval, and what conditions trigger revocation. Model Context Protocol: Authorization specification is the clearest reference for the OAuth-based resource-server model and the rejection of token passthrough.
What good MCP control design looks like in practice
Teams get into trouble when they rely on a single layer. A safer design uses annotations to inform the interface, authorization to enforce policy, and session management to constrain duration. That means the host can show tool intent, but the policy decision still happens separately, and the session is tied to the task rather than the agent’s general presence.
For MCP-specific implementations, it helps to check whether the server is acting like a real protected resource with its own authorization boundary, rather than a passive relay for whatever token the client already has. MCP Security Guide covers practical patterns such as OAuth-based authorization, token passthrough risks, and gateway controls. The IETF references for OAuth also matter here, especially RFC 6749: The OAuth 2.0 Authorization Framework and RFC 9728: OAuth 2.0 Protected Resource Metadata, because they reinforce how protected resources advertise and enforce access.
Risk and Threat Considerations
When teams mistake annotations for enforcement, the main risk is over-trust: a tool that looks harmless can still be invoked in a way that causes data exposure, destructive changes, or unintended downstream actions. When session authorization can be renewed by the agent itself, the boundary collapses and a narrow approval can become a persistence mechanism.
Failure mechanism: The host treats metadata as a control, or the agent can refresh or extend its own session without a fresh human or policy decision. That allows tool misuse, confused-deputy behavior, and privilege persistence after the original task should have ended.
Impact: Unauthorized actions can continue beyond the intended scope, and the system can lose both least privilege and traceability. In practice, that increases the blast radius of a compromised prompt, a misbehaving agent, or a malicious tool chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Covers agents exceeding intended authority in tool use. |
| ASI02 — Tool Misuse | Directly addresses unsafe or unintended tool invocation by agents. | |
| ASI10 — Rogue Agents | Relevant when an agent can act beyond its intended session boundary. | |
| Recommendation — Enforce separate policy checks for every privileged agent action. Constrain tool calls with per-action authorization and scoped approvals. Design sessions so unauthorized agent continuation is impossible. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tools expose callable functions that need explicit authorization. |
| API2 — Broken Authentication | Session renewal and token handling make auth integrity central here. | |
| Recommendation — Authorize each callable function independently of interface labels. Bind session tokens to task scope and revoke them at task end. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Session-scoped access should limit permissions to the minimum needed. |
| IA-5 — Authenticator Management | Session-scoped authorization depends on short-lived, well-managed credentials. | |
| AC-2 — Account Management | Task-bounded authorization depends on lifecycle controls for delegated access. | |
| Recommendation — Grant only the minimum permissions required for the current task. Expire or revoke task credentials when the task completes. Remove temporary access as soon as the approved task ends. | ||
Practitioner Guidance
What to verify: Verify that annotations only change presentation or routing, never the allow/deny decision. If a tool can change state, access sensitive records, or call external systems, confirm that the policy layer checks those actions independently of the annotation.
Decision rule: If the agent can renew its own access, treat the design as standing privilege and redesign the session boundary. If reapproval is required for the next task or a broader scope, the control is much closer to what teams usually intend.
Common mistake: Do not let “session-scoped” become “session-long” simply because the user stayed logged in or the agent stayed active. The safe pattern is task completion, revocation, and explicit reauthorization for anything materially different.
Practitioner takeaway: An MCP annotation is a claim about intent, but authorization is the authority, and the session must be short enough that the agent cannot convert temporary permission into durable access.
