Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

MCP-based architectures: why AppSec controls are losing context


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9223
Topic starter  

TL;DR: Traditional AppSec tools still matter, but they do not fully secure MCP-based agent architectures because they cannot reason about model intent, conversational context, or runtime tool orchestration, according to TROJ.AI. The governance problem is now the decision loop itself, where valid actions can combine into unsafe outcomes that legacy controls were never built to evaluate.

NHIMG editorial — based on content published by TROJ.AI: Why Traditional AppSec Tools Fail Against MCP-Based Architectures

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.
  • 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.
  • Tighten delegated identities for agent workflows Replace broad shared credentials with scoped identities that can be attributed to a specific actor, user, or task.

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.

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

MCP-based architectures: why AppSec controls are losing context?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8662
 

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.

A few things that frame the scale:

A question worth separating out:

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.

👉 Read our full editorial: MCP architectures expose a governance gap traditional AppSec misses



   
ReplyQuote
Share: