An MCP Call is a request made by an AI agent to a tool or data source through the Model Context Protocol. It carries the action, parameters, and context needed for the agent to retrieve information or trigger a function. In security terms, it is a governed interaction that should be authenticated, authorized, logged, and bounded.
What an MCP Call Actually Represents
An MCP Call is the active unit of interaction between an AI agent and an external capability, not just a message exchange. It is the moment where intent becomes executable, so the call itself becomes a security boundary that must be governed like any other privileged request.
That framing matters because the risk is rarely in the protocol name alone. The security question is whether the request is authenticated, whether the agent is allowed to invoke the tool, and whether the context passed into the call is appropriate for the action being requested.
Why MCP Calls Need Security Controls
An MCP Call can retrieve data, invoke functions, or chain into downstream systems, which means it may expose data, trigger side effects, or broaden trust if controls are weak. In a governed deployment, the call should be treated as a bounded action with explicit authorization, scoped permissions, and auditability, rather than a free-form tool invocation.
That is why MCP security discussions often center on access scoping, secret handling, and action boundaries. NHIMG’s The State of MCP Server Security 2025 highlights how often MCP deployments still expose credentials and lack tool scoping, showing that the protocol is only as safe as the controls wrapped around each call.
For agentic systems, the call is also where tool misuse can happen. If an agent can reach the right endpoint but not the right purpose, the protocol still becomes an abuse path because the request carries operational authority, not just data.
Authentication, Authorization, and Logging at the Call Layer
MCP Calls are most secure when the server can verify who or what is making the request, determine whether that request is in scope, and retain logs that support investigation. In practice, this means the call layer should reflect the same discipline used for service-to-service APIs, with identity, authorization, and traceability applied to each action.
The value of this model is that it separates transport from trust. A client may be able to reach an MCP server over a valid channel, but that does not mean every requested action is acceptable, especially when the call can touch sensitive data or operational tools.
External guidance for the protocol itself reinforces that principle. The Model Context Protocol: Authorization specification defines MCP servers as OAuth 2.1 resource servers for HTTP transports and emphasises audience-bound tokens instead of token passthrough.
That aligns with broader guidance for agent security, including the OWASP Agentic AI Top 10, which treats identity and privilege abuse as a first-order concern when agents can take actions through tools.
How MCP Calls Change the Agentic AI Threat Surface
An MCP Call expands the agent’s effective attack surface because it connects model output to real systems. If the call is poorly constrained, a prompt, tool-selection error, or poisoned context can move an agent from observation to action in a single step.
The main consequence is not just data exposure but unintended execution. Once a request can trigger retrieval, configuration changes, or downstream workflow steps, the protocol becomes part of the control plane for the agent, and failures in authorization or scoping can turn into broader compromise.
That is why MCP should be understood as a governed interface, not a convenience wrapper. The strongest security posture assumes every call may be sensitive until proven otherwise, especially when the target tool has write access, access to secrets, or visibility into privileged business data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | MCP calls need verified actor identity before tool execution. |
| AC-3 — Access Enforcement | MCP calls must enforce whether a request is allowed to invoke a tool or action. | |
| AU-2 — Audit Events | MCP calls should be logged as auditable tool and action events. | |
| Recommendation — Require authenticated identities before allowing MCP tool requests to execute. Enforce access decisions on each MCP call before the tool executes. Log MCP call events so tool use can be investigated and reconstructed. | ||
| OWASP ASVS | V8 — Authorization | The call boundary is an authorization decision point for tool use and scoped action. |
| Recommendation — Validate authorization before an agent can invoke a protected MCP action. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | An MCP call is function-like invocation and must block unauthorized actions. |
| Recommendation — Prevent agents from invoking MCP functions they are not permitted to use. | ||
