MCP changes the trust model because context can move between sessions, prompts, and agents in ways that are easy to misconfigure. If memory scopes, handoff rules, or prompt boundaries are weak, sensitive data can leak, instructions can be altered, and unauthorized agents can act on context they should never see.
Why MCP Controls Change the Security Problem
MCP-based systems do not just move data between tools. They move trust. In multi-agent environments, that means a prompt, memory object, or tool response can become a security boundary failure if the control plane assumes a stable human-style session model. Current guidance suggests the real risk is not MCP itself, but weak scoping around what an agent can read, retain, forward, or execute after context handoff. That is why NHI governance and agentic AI governance now overlap in practice.
This is especially visible in incidents where an agent inherits context from a prior task, then uses it in a new chain of actions that was never intended by the original operator. NHIMG’s AI Agents: The New Attack Surface report notes that 80% of organisations report agents have already performed actions beyond intended scope, including unauthorized system access and sensitive data sharing. For a deeper control lens, the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both point toward context-aware governance rather than static trust assumptions. In practice, many security teams discover MCP exposure only after an agent has already reused privileged context across a boundary that nobody formally defined.
How It Works in Practice
MCP controls become safer when they are treated as runtime authorization problems, not just integration problems. The practical goal is to bind each agent to a narrowly scoped workload identity, issue ephemeral access for a specific task, and evaluate policy at the moment a tool call is made. That is very different from giving a shared agent pool a long-lived token and hoping prompt rules will keep it disciplined.
A workable pattern is to separate three layers: identity, context, and action. Identity should be cryptographic and workload-based, such as SPIFFE-style workload identity or short-lived OIDC-backed tokens. Context should be bounded by task, with explicit memory scopes and handoff rules. Action should be checked through policy-as-code, where the system decides at runtime whether the specific agent, in the specific state, may call the specific tool with the specific data. The CSA MAESTRO agentic AI threat modeling framework and NIST Cybersecurity Framework 2.0 both support this style of layered control.
In NHI terms, this means favoring just-in-time credentials, short TTLs, and explicit revocation when the task ends. It also means treating prompt boundaries as enforceable policy surfaces, not as informal developer conventions. NHIMG’s OWASP NHI Top 10 and the CoPhish OAuth Token Theft via Copilot Studio case study both illustrate how easily tokens and delegated trust can be abused once an agent can chain tools across scopes. These controls tend to break down when multiple agents share a common memory store and a single broad service token because provenance and intent become impossible to verify per action.
Common Variations and Edge Cases
Tighter MCP controls often increase orchestration overhead, requiring organisations to balance agent agility against auditability and response latency. That tradeoff is real, especially in multi-agent pipelines where one agent summarises, another plans, and a third executes.
Best practice is still evolving for shared-memory architectures, and there is no universal standard for how long context should persist or which agent may inherit it. Some teams will need read-only context relays, while others will need per-hop reauthorization for high-risk actions. The hardest edge case is cross-agent delegation: when one agent can hand off partial authority to another, the original policy may no longer describe the effective risk. This is where static RBAC breaks down and intent-based authorization becomes more credible, because the question is not only who the agent is, but what the agent is trying to do right now.
Security teams should also expect failures in environments that mix human chat, automation, and tool execution in a single session. Prompt injection, memory poisoning, and hidden tool instructions can all change the meaning of a previously approved request. NHIMG’s Gemini AI Breach — Google Calendar Prompt Injection is a useful example of how context misuse can turn into data exposure. The cleanest control is not a bigger prompt policy, but a narrower trust domain with explicit hop-by-hop verification and rapid token revocation.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agent tool misuse and prompt boundary failures are central to MCP risk. |
| CSA MAESTRO | TA-2 | MAESTRO addresses agent threat modeling across tools, memory, and delegation. |
| NIST AI RMF | GOVERN | AI RMF governance fits runtime oversight for autonomous MCP-driven agents. |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP deployments rely on secret handling and short-lived credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is required when agents can move context between tools. |
Use ephemeral credentials, scope them tightly, and revoke them immediately after use.
Related resources from NHI Mgmt Group
- Why do header-based routing controls create new MCP security risks?
- Why do AI-generated MCP tools and agent workflows create a different security risk than ordinary application code?
- Why do AI agent security risks require immediate attention?
- What is the difference between agent identity controls and runtime containment for AI security?
