LLM discovery and MCP security are becoming core AppSec issues

At a glance

What this is: This is Pynt’s analysis of why LLM discovery and MCP security are becoming central to application security testing, with a focus on emerging exposure patterns and testing gaps.

Why it matters: It matters because IAM, PAM, and security architecture teams now have to govern AI-connected tool access, secrets, and runtime behaviour alongside traditional application controls.

By the numbers:

• 98% are adopting LLMs into apps, while only 24% have onboarded security tools.
• Only 24% have onboarded security tools for LLM-enabled applications.

👉 Read Pynt's analysis of LLM discovery and MCP security risks

Context

LLM security is moving from a niche concern to an application security and governance issue because AI features now sit inside production workflows, not outside them. Once an LLM can retrieve context, call tools, or touch sensitive data, the security model expands beyond prompt quality into access control, data exposure, and runtime trust. In that sense, the article is really about how AI-enabled applications create new control boundaries that existing AppSec programmes often do not yet cover.

For IAM and identity practitioners, the important intersection is not the model itself but the identities and permissions attached to it. MCP-connected agents, service accounts, API keys, and delegated access paths all become part of the trust chain. That makes discovery, authorisation, and monitoring as important as testing the application layer, and the current maturity gap is typical rather than exceptional.

Key questions

Q: What breaks when AI agents are discovered too late or not at all?

A: When agents are not discovered early, teams cannot assign ownership, set scope, or prove what systems the agent can reach. That leaves shadow AI outside IAM, IGA, and PAM oversight. The result is unmanaged identity growth, weak auditability, and limited ability to contain misuse or offboard the agent cleanly.

Q: Why do LLM applications create governance problems for IAM and security teams?

A: LLM applications create governance problems because they can turn untrusted input into live system behaviour. Once a model can call tools, reach internal data, or shape business logic, access control, output handling, and runtime policy become one control surface. That requires identity and application governance to be designed together.

Q: How can teams tell whether AI security workflows are actually reliable?

A: Check whether the workflow produces consistent results from the same underlying evidence and whether it preserves the relationship between findings, identities, and assets. Reliable workflows reduce rework, surface the right context on the first pass, and generate remediation steps that still make sense when reviewed against the live environment.

Q: Should organisations treat MCP-connected AI systems like privileged workloads?

A: Yes. MCP-connected systems can invoke tools, reach data, and trigger actions, which means they function more like privileged workloads than passive applications. They need least privilege, logging, access review, and clear ownership. If a model can act on behalf of a user or service, its permissions deserve the same scrutiny as any elevated account.

Technical breakdown

LLM discovery as a security boundary

LLM discovery is the process of finding where language models, assistants, and AI-enabled workflows exist across an environment, including embedded features inside applications, developer tools, and internal automations. Security teams cannot protect what they cannot map, which is why discovery is now a prerequisite for testing. In practice, discovery must include connected services, tool-calling paths, and any data sources the model can reach. Without that inventory, security testing only covers the visible surface while the real attack paths remain hidden in integrations and orchestration layers.

Practical implication: build an authoritative inventory of LLM-enabled applications, their tool connections, and the identities they use before expanding test coverage.

MCP security and tool-call trust

The Model Context Protocol connects AI agents to tools and data sources, which means the security problem is not just model output but delegated action. MCP expands the blast radius of an LLM because a successful prompt or workflow manipulation can translate into tool use, data access, or operational change. The control challenge is to enforce least privilege, explicit scoping, and monitoring around every tool a model can invoke. In identity terms, the agent becomes a runtime actor with permissions that must be governed like any other privileged workload.

Practical implication: treat MCP tool permissions as privileged access and review them with the same discipline used for service accounts and automation credentials.

Why security testing must move from static to behavioural

Traditional security testing looks for known application flaws at a point in time, but LLM-enabled systems behave dynamically and can change outputs based on context, retrieval content, and tool access. That makes behavioural testing more valuable than static checks alone. Effective testing looks at prompt injection, data exfiltration paths, tool misuse, and excessive authorization rather than only code defects. The key shift is that security validation must follow the model’s runtime decisions, not just the application’s source code or build artefacts.

Practical implication: add runtime and adversarial testing for prompt, retrieval, and tool-use paths instead of relying on pre-deployment scans alone.

Threat narrative

Attacker objective: The attacker wants to use AI-enabled workflows as a trusted pathway to access data, invoke tools, or trigger actions outside intended scope.

1. Entry occurs when an LLM-enabled application exposes discovery gaps, allowing hidden AI workflows or MCP-connected tools to remain unreviewed.
2. Escalation occurs when the model inherits broader tool permissions than the use case requires, turning a conversational interface into a privileged execution path.
3. Impact occurs when an attacker manipulates the model or its context to trigger unauthorized data access, sensitive disclosure, or unintended actions.

NHI Mgmt Group analysis

LLM discovery is now an identity governance problem, not just an AppSec hygiene task. When AI features can retrieve data and call tools, the real question is which identities, secrets, and permissions sit behind the model. Discovery therefore becomes a control boundary for IAM and PAM teams, because unmanaged AI workflows behave like shadow workloads with delegated authority. Practitioners should treat hidden AI integrations as part of the governed identity estate.

MCP creates a new privileged action layer for AI systems. The protocol is valuable precisely because it standardises tool and data connectivity, but standardisation also concentrates risk if permissions are broad or poorly segmented. The governance challenge is not the protocol itself, but the assumption that an LLM can safely inherit the rights of the user or service account behind it. Practitioners should map MCP permissions to least-privilege policy and review them as privileged access.

Behavioural testing is the right response to agentic runtime risk. Static checks miss the fact that LLMs can change behaviour based on retrieval content, prompt inputs, and tool responses. That creates a control gap between design-time approval and runtime action. AI governance debt: the backlog of unclassified AI workflows, unscoped tool permissions, and untested interaction paths that accumulates faster than policy can keep up. Practitioners should close that debt by combining discovery, authorisation, and runtime validation.

Identity teams should expect AI security to converge with zero trust principles. The model, its tools, and its data sources should never be assumed safe simply because they sit inside the enterprise boundary. Continuous verification, explicit scoping, and session-level monitoring matter because AI systems can chain actions in ways traditional application controls do not anticipate. Practitioners should align AI controls with zero trust and privileged access governance rather than treating them as a separate domain.

What this signals

AI governance debt: the gap between deployment speed and policy coverage is becoming the main programme risk for teams adopting LLMs. As AI features spread into production apps, discovery and access scoping need to happen before the first serious incident rather than after the first audit finding. That makes AI security an operating model issue, not a tooling refresh.

Teams should expect MCP-connected applications to force closer alignment between AppSec, IAM, and PAM. The security boundary is no longer just the codebase or the model endpoint. It now includes the identities, secrets, and delegated permissions that let the model interact with business systems, which means governance has to span runtime access as well as static reviews.

For practitioners

• Implement continuous LLM and MCP discovery Create a living inventory of every AI-enabled application, agent, retrieval source, and tool endpoint. Include the identities, keys, and service accounts behind each connection so hidden AI workflows cannot evade governance.
• Scope MCP tool permissions as privileged access Review each tool-call path as if it were a privileged workload. Limit actions to the minimum set required, separate read and write capabilities, and require periodic recertification for any credential or token that can invoke external systems.
• Add adversarial runtime tests for AI workflows Test prompt injection, retrieval poisoning, and tool misuse in the same way you would test abuse paths in a high-risk application. Validate how the model behaves when context is malicious, incomplete, or unexpectedly broad.
• Tie AI governance to IAM and PAM reviews Bring AI agents, automation accounts, and API tokens into the same review cycle as other privileged identities. Reassess ownership, expiry, and logging so the model cannot outpace the controls around it.

Key takeaways

• LLM-enabled applications expand the security boundary from code into runtime identity, access, and tool governance.
• The biggest control gap is not model capability alone, but the hidden identities and permissions attached to AI workflows.
• Practitioners should combine discovery, least privilege, and behavioural testing before agentic systems become routine production dependencies.

Key terms

• LLM Discovery: LLM discovery is the process of locating where language models and AI-enabled workflows exist across the environment. It includes embedded features, developer tools, retrieval paths, and the identities or credentials that let those systems reach data and external services.
• MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Tool-Call Path: A tool-call path is the route by which an AI model or agent invokes an external service, API, or internal system. It matters because each call can carry real authority, making the path a privileged transaction that needs scoping, logging, and review.

What's in the full article

Pynt's full article covers the operational detail this post intentionally leaves for the source:

• Specific findings from its LLM security research and the testing patterns it used to surface risk
• More detail on Pynt's product-led approach to discovery and testing across AI-enabled applications
• Examples of the application security use cases and control gaps the article highlights for practitioners

👉 Pynt's full post covers the testing focus, workflow exposure patterns, and product context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in practical terms. It helps identity and security practitioners connect modern access patterns to accountable controls across their programmes.