MCP architectures expose a governance gap traditional AppSec misses

At a glance

What this is: This is a practitioner analysis of why traditional AppSec is incomplete for MCP-based agent architectures, with the key finding that runtime context and tool orchestration create risks legacy controls miss.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent-mediated actions, delegated access, and identity attribution across workflows that behave more like operators than applications.

👉 Read TROJ.AI's analysis of why traditional AppSec tools fail against MCP architectures

Context

Model Context Protocol changes the security problem from protecting isolated requests to governing a decision loop that can discover tools, select them, and act across systems. In that model, the primary keyword is MCP, and the central gap is that traditional AppSec assumes deterministic control flow, while agentic workflows are iterative and context-heavy.

For identity programmes, the issue is not whether existing AppSec should be removed. It is whether the controls around identities, authorization, attribution, and tool trust can handle non-human actors that initiate actions at runtime. That pulls NHI governance, delegated authorization, and lifecycle controls into the same operational conversation. The question is no longer only what input is safe, but who or what is allowed to act on the output.

Key questions

Q: How should security teams govern MCP-based agent workflows?

A: Security teams should govern MCP-based workflows by treating the agent loop as the control surface. That means mapping tool discovery, action sequencing, delegation, and provenance, then applying identity and authorization checks at the point where the agent decides to act. Traditional request filtering remains useful, but it is not enough on its own.

Q: Why do traditional AppSec tools fall short for agentic AI?

A: Traditional AppSec tools fall short because they are designed to inspect code, requests, or dependencies, not the meaning of an evolving tool chain. In agentic systems, the danger often appears only after several valid steps combine into an unsafe outcome. That makes sequence control and identity attribution essential.

Q: What do security teams get wrong about AI agent authorization?

A: Teams often grant broad access up front because they assume the agent may need it later. That widens blast radius and weakens attribution. The better model is narrow, task-scoped delegation with explicit accountability for each step that can change data, systems, or external communications.

Q: How do you know if MCP tooling is creating hidden risk?

A: You know risk is emerging when individual tool calls look legitimate but the combined sequence produces outcomes the business did not intend, such as exporting data, changing configuration, or publishing sensitive content. If you cannot trace the prompt, the document, and the tool output that shaped the action, the workflow is not governable.

Technical breakdown

Why MCP changes the attack surface

MCP formalises how agents discover tools, call them, and use the results to decide what happens next. That creates a loop of plan, call, observe, and repeat, which is very different from a fixed request-response application. The security boundary therefore expands from a single endpoint to the tool graph, the broker layer, the returned content, and the logic that decides the next action. Risks emerge when those components are individually valid but collectively unsafe.

Practical implication: treat the tool graph as a governed control plane, not a convenience layer.

Why traditional AppSec tools lose context

SAST, DAST, API testing, SCA, and perimeter controls all assume relatively stable inputs, known endpoints, and predictable execution paths. MCP breaks that assumption because the same prompt can produce different tool chains, and a harmless-seeming action can become risky only in sequence with later steps. Traditional tools can test requests, code, or dependencies, but they do not naturally evaluate semantic intent, tool provenance, or chained outcomes across multiple systems.

Practical implication: add agent-aware control checks where sequence risk, not just endpoint risk, is the failure mode.

Identity and authorization in agent-driven workflows

Many agents operate under shared tokens, coarse service identities, or broad developer credentials, which makes attribution and delegated authority difficult to prove. When an agent acts for multiple users, identity boundaries blur and least privilege is often widened pre-emptively. That creates a governance problem for access review, per-step authorization, and accountability, because the decision to act may be made by the agent at runtime rather than by a human requestor at the edge.

Practical implication: require identity attribution and scoped delegation at the action level, not just at session start.

Threat narrative

Attacker objective: The attacker wants to turn valid agent actions into a controlled execution path that leaks data or triggers unauthorized changes without tripping traditional request-level controls.

1. Entry occurs when an attacker manipulates prompts, retrieved content, or an untrusted MCP tool so the agent accepts malicious instructions as part of the workflow.
2. Escalation happens when the agent chains multiple legitimate tool calls, allowing read-capable and write-capable capabilities to combine into unsafe actions such as data export or unauthorized posting.
3. Impact is achieved when the agent completes a harmful sequence that moves sensitive data, changes configurations, or extends attacker influence across connected systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Traditional AppSec assumes that control is exercised at the request boundary, but MCP moves control into the decision loop. That assumption was designed for deterministic applications that process fixed inputs and return bounded outputs. It fails when the actor can discover tools, interpret results, and choose the next action at runtime. The implication is that security programmes must stop treating endpoint validation as the main line of defence and start governing the loop where decisions are made.

Tool chaining creates a distinct identity risk: individually safe actions can become unsafe when combined. The article’s clearest point is that risk does not always live in a single request. A read tool and a write tool, or a summary step and a publishing step, can form an exfiltration path without any one component looking malicious. That is a governance blind spot for NHI and agentic control models alike, because access review at the endpoint level does not capture sequence risk. Practitioners need to recognise identity blast radius as a property of action combinations, not just permissions.

Model Context Protocol creates a runtime governance gap because trust is no longer static. Runtime context drift: that is the named concept this article surfaces. The model does not preserve stable intent, and external content can change what the agent believes is safe or relevant. For identity governance, this means provenance, delegation, and authorization must be understood as dynamic and stateful, not as one-time checks. Practitioners should treat trust as something that can change between tool calls.

Identity attribution becomes murky once agents act across multiple users and systems. Shared service identities, broad tokens, and developer keys may keep workflows moving, but they also blur who approved what and who should be held accountable afterward. That is not just an audit inconvenience. It weakens the governance case for least privilege, because the programme cannot clearly map action to actor. The practical conclusion is that delegation chains need explicit ownership and review logic before agentic workflows are scaled.

MCP does not replace AppSec, but it does relocate the highest-value control points. The article is right that traditional controls remain necessary. The broader field implication is that identity, provenance, and tool trust are now first-class security problems in AI-enabled architectures. That means the market is moving toward controls that understand context, not just traffic, and practitioners should evaluate whether their current stack can actually see agent behaviour end to end.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, 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, according to AI Agents: The New Attack Surface report.
• For a broader framework on runtime trust and control, see OWASP Agentic Applications Top 10, which helps teams evaluate agent tool misuse and context-driven failure modes.

What this signals

Runtime context drift: MCP-based systems create governance conditions where the meaning of an action can change between planning and execution. Security teams should expect audit, authorization, and review processes to break when they still assume a stable request boundary, and they should prepare for controls that can see tool provenance and action sequences.

With 92% of organisations agreeing that governing AI agents is critical but only 44% having implemented policies, the programme risk is not theoretical. Teams that already manage NHI and IAM will need to decide whether their current identity model can absorb agent-driven delegation, or whether it needs a separate control layer tied to runtime trust.

The practical signal for identity leaders is that MCP risk is showing up at the intersection of NHI, authorization, and observability. If your logs do not tell you which prompt, tool, and output drove the decision, then the workflow is already outside normal governance reach.

For practitioners

• Map agent decision loops end to end Inventory where agents read, decide, call tools, and act, then document every point where the sequence can change a real system. Focus on the broker layer, tool outputs, and any path that turns a read action into a write action.
• Separate endpoint validation from sequence governance Keep WAF, API testing, and SAST in place, but add controls that evaluate whether a valid series of actions is acceptable in context. Prioritise cases where harmless individual steps could become data exposure or unauthorized change when chained.
• Tighten delegated identities for agent workflows Replace broad shared credentials with scoped identities that can be attributed to a specific actor, user, or task. Require per-step authorization for high-impact actions so the agent cannot silently expand privilege mid-workflow.
• Track provenance for prompts and tool outputs Log which prompt, retrieved document, or tool result influenced each agent decision, then make those traces available to investigation and access review. Without provenance, incident response will not be able to explain why the agent acted.

Key takeaways

• MCP-based agent architectures break the assumptions behind traditional AppSec because they move risk into runtime decision-making, not just endpoint validation.
• The core evidence is sequence risk: valid individual actions can combine into unsafe outcomes that legacy tools do not evaluate well.
• Identity teams should respond by governing delegation, provenance, and per-step authorization instead of relying on request-level controls alone.

Key terms

• MCP-based architecture: An MCP-based architecture uses Model Context Protocol to let agents discover and call tools through a formal integration layer. The security issue is that tool use becomes part of the decision process, so control must extend beyond single requests to include the sequence of actions and the trust placed in returned content.
• Tool chaining: Tool chaining is the linking of multiple tool calls into one agent workflow, where each step may look valid on its own. The risk appears when those steps combine into an outcome the organisation did not intend, such as exfiltration, unauthorised posting, or configuration change.
• Provenance: Provenance is the ability to show where a prompt, document, or tool output came from and how it influenced a decision. In agentic systems, provenance is not a nice-to-have audit field. It is the evidence needed to explain action, challenge trust, and investigate misuse.
• Delegated identity: Delegated identity is an identity used by one actor to act on behalf of another, such as an agent acting for a user or service. In agentic workflows, delegation must be tightly scoped and attributable, or broad credentials will blur accountability and expand blast radius.

What's in the full article

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

• A deeper breakdown of the specific attack types discussed for MCP environments, including prompt injection, tool poisoning, and rug pulls.
• Expanded examples of where SAST, DAST, SCA, secrets scanning, and perimeter controls lose visibility in agent workflows.
• The article's own explanation of how agent behaviour differs from deterministic API security in practice.
• Further detail on why runtime trust, provenance, and delegation become core security requirements for MCP-based architectures.

👉 TROJ.AI's full post covers the MCP attack surface, control gaps, and agent-specific failure modes 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 building or maturing identity security in your organisation, it is worth exploring.