The gap is that access can be valid while behaviour is malicious. MCP security can log and constrain tool access, but without runtime protection a prompt injection or poisoned tool descriptor can redirect the agent after authentication and still complete harmful actions inside the same session.
Where MCP Security Stops and Runtime Protection Starts
mcp security is about whether the session, transport, and authorization path are legitimate. Runtime protection is about whether the agent’s live behaviour is still trustworthy after access has already been granted. The break appears when those two are treated as the same control, because a validly authenticated session can still be steered into harmful actions by prompt injection or a poisoned tool descriptor.
That distinction matters most in agentic workflows, where the tool call may be technically permitted even while the intent behind it has been subverted. In practice, the security boundary is no longer just “can this client connect?” but “can this session still be trusted to execute the intended workflow?” For a broader control view of that boundary, the MCP Security Guide separates authorization and token handling from the runtime abuse patterns that can follow.
When protection is missing, the agent can continue to operate inside an apparently valid session while its decisions have been redirected. That is why MCP security by itself is necessary but not sufficient: it can authenticate and constrain entry, yet it does not automatically detect poisoned instructions, malicious tool metadata, or post-authentication task drift. The result is a control gap between access validity and behavioural integrity.
What Actually Breaks in the Session
The broken element is not login, transport, or initial permissioning. What breaks is the assumption that authorised access implies trustworthy execution. Once the agent is inside the session, attacker-controlled instructions can turn the same permitted capability into a harmful action chain, especially if the system trusts the content of tool descriptors or prompt context too far.
This is why runtime protection has to treat the session as an active decision surface, not a static authentication event. The agent needs guardrails that can detect when a tool invocation no longer matches the intended task, when a descriptor introduces unsafe instructions, or when a seemingly valid workflow has been redirected into data exfiltration, overbroad actions, or unsafe side effects. The OWASP Agentic AI Top 10 is useful here because it frames tool misuse, agent goal hijacking, and identity or privilege abuse as runtime risks rather than simple access-control failures.
That distinction also explains why mcp protection and MCP security are not interchangeable. Security can say the request is authenticated and authorised; protection has to answer whether the request is still behaviourally safe after the agent has been exposed to untrusted context. In an MCP environment, the missing piece is often continuous scrutiny of the tool-call intent itself.
Why the Gap Matters to Practitioners
Practitioners should read this as a control-composition problem. If you only enforce MCP security, you may still allow harmful actions that are technically valid within the same session. If you only add runtime monitoring without strong access control, you leave too much authority in the hands of anything that can reach the tool surface. The control objective is to make access and behaviour independently defensible.
- Assume tool descriptors, prompts, and retrieved context are untrusted inputs unless they have been explicitly bounded.
- Treat session continuity as conditional, not as proof that later actions are still legitimate.
- Separate “can connect” from “can act” from “can continue acting safely” in your control design.
- Use least-privilege scoping so a compromised session cannot escalate simply because it remains authenticated.
For teams implementing MCP, the strongest operational discipline is to pair protocol-level authorization with runtime policy checks on tool use, output, and side effects. That is the difference between a system that merely logs access and one that can still stop a malicious turn mid-session. The Model Context Protocol: Authorization specification is the protocol reference for the access side of that split, while the runtime side still has to be engineered above it.
Risk and Threat Considerations
When MCP protection is missing, the main risk is post-authentication abuse: the session remains valid while the agent is redirected into actions the user never intended. Prompt injection and poisoned tool descriptors are especially dangerous because they exploit trusted execution paths rather than breaking them.
Failure mechanism: An attacker smuggles malicious instructions into context or tool metadata, then relies on the agent to follow them after authentication has already succeeded. The session still looks legitimate to MCP security controls, so harmful tool calls can complete under the cover of valid access.
Impact: The result can be unauthorized data access, unsafe writes, workflow manipulation, or broader action abuse inside a trusted session. At scale, this becomes a governance problem as well as a security problem, because logs may show authorised activity even when the behaviour was adversary-driven.
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 MITRE ATT&CK address 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 |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tool abuse is a runtime agent risk. |
| ASI01 — Agent Goal Hijack | Prompt injection can redirect agent intent after access. | |
| ASI03 — Identity & Privilege Abuse | Valid sessions can still be abused through excessive runtime authority. | |
| Recommendation — Add runtime checks that stop unsafe tool actions. Detect and block goal drift before execution continues. Constrain agent privileges so authenticated access stays bounded. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted prompts and tool descriptors need validation controls. |
| AC-6 — Least Privilege | Session access must be bounded even after authentication succeeds. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Runtime abuse needs detection and review of suspicious activity. | |
| Recommendation — Validate external inputs before they influence agent actions. Limit tool and data access to the minimum required authority. Review agent action logs for anomalous post-authentication behaviour. | ||
| OWASP ASVS | V8 — Authorization | Runtime tool use must remain authorised beyond the initial session grant. |
| V16 — Security Logging and Error Handling | Abuse detection depends on usable logs for agent action paths. | |
| Recommendation — Enforce authorization checks on each sensitive action. Log agent tool calls and suspicious policy violations. | ||
| MITRE ATT&CK | T1204 — User Execution | Prompt injection and poisoned instructions rely on trusted execution paths. |
| Recommendation — Map instruction-abuse paths to detections that catch malicious task steering. | ||
Practitioner Guidance
What to prioritise: Put runtime guardrails on the tool decision path before you expand MCP integrations. The most important control question is not whether the session authenticated, but whether each meaningful tool action is still aligned with the intended task and current policy.
What to verify: Verify that you can distinguish authorised access from authorised intent, and that your runtime layer can block or quarantine suspicious tool calls without depending on the original login event. If you cannot do that, your MCP security posture is incomplete.
Practitioner takeaway: Treat MCP security as the entry control and MCP protection as the behavioural control, because a valid session that has been redirected is still a compromise even when the authentication path was correct.