By NHI Mgmt Group Editorial TeamPublished 2025-07-10Domain: Agentic AI & NHIsSource: TROJ.AI

TL;DR: Model Context Protocol standardises how AI models call tools, use memory, and carry context, which can improve traceability and access control but also expands the attack surface for agentic systems, according to TROJ.AI. For identity teams, the real issue is not interoperability itself but whether governance keeps pace with dynamic tool use and auditable context boundaries.


At a glance

What this is: This is an analysis of Model Context Protocol, an open standard for structuring how AI models interact with tools, memory, and data, with the key finding that standardisation can improve control while also broadening the agentic AI attack surface.

Why it matters: It matters because IAM, PAM, and NHI teams need to decide whether MCP becomes a governance aid or a new pathway for tool abuse, overbroad access, and weak accountability in autonomous workflows.

By the numbers:

👉 Read TROJ.AI's analysis of Model Context Protocol for secure AI systems


Context

Model Context Protocol, or MCP, is a structured way for AI models to exchange context with tools, APIs, memory, and other systems. The identity question is not whether the protocol is elegant, but whether it creates a more governable boundary for agentic AI or simply standardises the path to broader access.

For IAM and NHI programmes, MCP sits in the uncomfortable middle between application integration and runtime authorisation. The article frames it as an interoperability layer, but the governance problem is older: once models can select tools and consume context dynamically, teams need explicit control over who can do what, against which data, and under what conditions.

That is why MCP belongs in the same conversation as agent identity, workload identity, and access governance. It is most useful when security teams treat it as a control surface, not just a developer convenience.


Key questions

Q: How should security teams govern AI agents that use MCP to call tools?

A: Security teams should treat every MCP tool call as an access decision, not a technical convenience. The model, the session, the tool, and the data source all need explicit policy boundaries. That means scoping permissions per task, logging each invocation, and requiring human review for actions that can change data, state, or downstream access.

Q: Why does MCP increase the importance of runtime authorisation for agentic AI?

A: MCP increases the importance of runtime authorisation because it turns tool use into a dynamic, session-based decision path. If a model can choose when to call tools and which context to use, static approvals lose precision. Runtime controls keep the agent within the task scope that was actually intended, not the one assumed at design time.

Q: What breaks when AI agent context is treated like passive metadata?

A: What breaks is the boundary between information and authority. In MCP-driven systems, context can influence tool choice, memory, and downstream action. If teams treat it as harmless metadata, they miss the fact that context can carry instructions, shape decisions, and expand the model's effective privileges across systems.

Q: Who should own governance for MCP-connected AI systems?

A: Governance should sit with the teams responsible for identity, access, and application risk, not only with application developers. MCP creates shared responsibility across IAM, security engineering, and platform teams because tool access, context handling, and session policy all shape the real control environment.


Technical breakdown

How MCP structures tool calls and context transfer

MCP standardises how an application packages context, such as messages, files, instructions, and tool metadata, before passing it to a model. Instead of relying on ad hoc prompt stuffing or bespoke adapters, the protocol defines a predictable exchange format for function calls and context state. That improves interoperability, but it also makes the model's operational boundary more explicit. In security terms, the protocol does not remove privilege, it formalises where privilege can flow. If the context bundle includes data, instructions, and tool access, then each of those elements becomes part of the runtime trust decision.

Practical implication: security teams should review which context objects are admissible before a model call, not just which API keys are stored.

MCP, memory, and stateful agent identity

A key MCP claim is that it gives models memory and continuity across interactions. That matters because state changes the trust model. A stateless prompt can be evaluated in isolation, but a stateful session can carry prior instructions, retrieved data, and partial task context into later actions. For agentic systems, that means identity is no longer just about authentication at the start of a session. It is also about whether the model is still acting within the scope that was approved when memory, tools, and context were first exposed. The governance challenge is session drift, not just login control.

Practical implication: audit session-scoped context persistence and define when memory should expire, reset, or be excluded from tool execution.

Why MCP changes the control plane for AI agents

MCP matters because it turns separate integrations into a common control surface for tool access, context injection, and observability. That can improve auditability if the protocol is paired with strict policy enforcement, but it can also widen blast radius if the same structured interface is allowed to reach too many services. For autonomous behaviour, the issue is not only what the agent can call, but when and why it can decide to call it. That makes MCP relevant to zero trust thinking, because policy must govern every tool invocation and every data boundary, not just the initial model request.

Practical implication: treat MCP as a policy enforcement point and map every tool route to an access reviewable entitlement.


Threat narrative

Attacker objective: The objective is to make the AI system perform actions or retrieve data that exceed its approved scope while remaining difficult to distinguish from legitimate tool use.

  1. entry via a standardised AI-to-tool interface that accepts structured context and tool requests from the model session.
  2. escalation through broader tool reach, where a model can invoke internal APIs, documents, or memory objects beyond the intended task scope.
  3. impact through unaudited context-driven actions, producing overexposure of data, unauthorized operations, or hard-to-trace agent behaviour.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

MCP is becoming the identity control plane for agentic AI, not just a developer protocol. Once a model can call tools, retrieve context, and persist memory through a standard interface, the governance problem shifts from integration design to authority design. That means every MCP route becomes part of the effective identity perimeter, even when no human is in the loop. Practitioners should treat MCP as an entitlement boundary, not a messaging convenience.

Standardised tool access does not equal safe tool access. MCP can make agent behaviour easier to observe, but observability is not the same as restriction. If the protocol is used to connect models to internal systems without per-tool policy and session scoping, it can expand the attack surface faster than teams can inventory it. The implication is that governance must bind context, tool, and session together, or the protocol simply industrialises overreach.

Tool-routing semantics: the same structured path that improves interoperability can also create identity blast radius when permissions are too broad. That is the right concept for this category because the risk is not only unauthorized access, but the speed with which one model session can reach multiple systems. Security teams should map each MCP connection to a discrete trust boundary and a named owner.

MCP validates the need for agent identity governance to move beyond static credentials. Traditional access reviews assume a stable account, a stable role, and a stable system boundary. Agentic AI breaks that pattern because access can be assembled dynamically from context, memory, and tool choice. Practitioners should expect their governance model to shift from entitlement lists to runtime policy enforcement and evidence of approved tool use.

The weakest assumption in current agent governance is that context is harmless. MCP turns context into operational input, which means documents, instructions, and memory are no longer passive references. They become part of the decision surface that determines what the model can do next. The implication is that identity and data governance can no longer be separated cleanly when models act on both in the same session.

From our research:

  • 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
  • Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
  • Forward-looking implication: with 92% saying AI agent governance is critical but only 44% having policies in place, the control gap is already larger than the deployment curve, and the same research points to accelerated AI agent adoption in the next 12 months.

What this signals

AI agent identity is moving into the same governance class as machine identity. As protocol layers like MCP standardise tool use, security teams will need inventory, ownership, and approval models that can follow the agent at runtime. The practical signal is that access management will increasingly depend on session evidence, not just entitlement snapshots.

Runtime policy will matter more than integration elegance. If an agent can dynamically assemble context and choose tools, the control point has to move closer to execution. Practitioners should prepare for more pressure on policy engines, audit trails, and evidence collection across model, tool, and data boundaries.

With 80% of organisations already reporting AI agents acting beyond intended scope, per AI Agents: The New Attack Surface report, the likely next phase is not whether agentic AI gets deployed, but whether identity teams can prove what those agents were allowed to do.


For practitioners

  • Inventory MCP-connected tools and data sources Map every model-to-tool route, owner, and approved purpose before expanding agent usage. Include internal APIs, memory stores, retrieval layers, and document systems so access reviews can cover the full execution path, not just the model endpoint.
  • Bind policy to each tool invocation Require runtime checks for every MCP call, including data sensitivity, session state, and task scope. Do not rely on a one-time approval at session start if the model can continue to act after context changes.
  • Separate read context from act context Keep reference material, user instructions, and action permissions in different policy domains. A model that can read a source should not automatically be able to use that source to trigger downstream actions.
  • Review memory retention as an identity control Set explicit expiry and reset rules for persistent context, especially where memory influences later tool use. Treat retained context as privileged state that needs ownership, logging, and revocation criteria.

Key takeaways

  • MCP is not just an interoperability layer, it is a governance boundary that determines how far an AI agent can reach.
  • When tools, memory, and context share one control surface, overbroad access becomes a runtime identity problem rather than a developer issue.
  • Teams that cannot evidence per-session tool use will struggle to govern agentic AI at the speed the protocol enables.

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 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.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A1Covers tool misuse and agent authority risks central to MCP-connected systems.
NIST AI RMFAddresses governance and accountability for autonomous AI behaviour in runtime.
NIST CSF 2.0PR.AC-4Access control and least privilege apply when agents can call tools and reach data.

Assign ownership for agent actions and require policy evidence for every tool-enabled session.


Key terms

  • Model Context Protocol: A standard that defines how AI models exchange context with tools, memory, and data sources during a session. In practice, it creates a structured path for model input and tool invocation, which makes interoperability easier but also turns context handling into an access control problem.
  • Agentic AI: AI systems that can choose actions and call tools during runtime rather than only generating responses. In governance terms, agentic AI changes identity controls because the system can move from passive output to active execution, which requires tighter policy, auditing, and scope enforcement.
  • Tool-routing semantics: The policy rules that determine which tools, data sources, or services an AI model may invoke in a given session. This is a useful identity term because it describes the operational path where context becomes authority, and where overbroad access can turn into real-world action.
  • Session-scoped authority: The permissions and decision limits that apply to a model or agent during one active interaction. Unlike static account privileges, session-scoped authority depends on context, memory, and runtime policy, so it must be evaluated continuously rather than assumed from initial setup.

What's in the full article

TROJ.AI's full article covers the operational detail this post intentionally leaves for the source:

  • The step-by-step explanation of how MCP structures context, tool calls, and state across an AI session.
  • The article's discussion of why MCP reduces bespoke integrations while still requiring custom adapters for many proprietary systems.
  • The vendor's mapping of MCP to agentic workflows, including dynamic context routing and multi-agent coordination.
  • The source's own framing of how MCP fits into secure AI application design and developer workflow decisions.

👉 TROJ.AI's full article explains the MCP architecture, security benefits, and agent workflow implications in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-07-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org