LLM discovery and MCP security are becoming core AppSec issues

At a glance

What this is: Pynt frames LLM discovery and MCP security as emerging appsec governance problems, with the core issue being that teams cannot secure what they have not fully discovered or continuously validated.

Why it matters: For IAM, AppSec, and NHI practitioners, this matters because AI-enabled applications now blend APIs, service identities, and agent-like runtime behaviour into one control surface.

Context

LLM security is no longer just about model prompts or content filtering. As AI features move into production applications, the governance problem shifts to discovery, access control, and testing of the surrounding services, APIs, and machine identities that let those features operate.

MCP makes that shift more visible because it standardises how agents and tools connect to data and actions, but it also expands the surface where secrets, permissions, and trust relationships can fail. The article’s core point is that appsec teams now have to govern AI-enabled application behaviour, not just scan code before release.

That position is typical for organisations moving from experimentation to production AI. The hard part is not adding another test, but proving that every LLM- or MCP-enabled path is inventoried, authorised, and monitored as part of normal security operations.

Key questions

Q: What breaks when LLM discovery is incomplete in application security programmes?

A: When discovery is incomplete, teams miss where AI features actually run, which means testing scope, ownership, and control coverage are all partial. That leaves prompts, tool calls, and integration paths outside normal governance. The result is not just weaker visibility, but a false sense of assurance that the application estate is covered.

Q: Why do MCP-connected tools increase appsec and IAM risk?

A: MCP-connected tools increase risk because they turn an AI workflow into a privileged integration path that can reach data and actions across multiple systems. If tokens, scopes, or authorisation are broad, one weak connection can expose more than the original application intended. The control question is whether each tool path is least privileged and revocable.

Q: How do security teams know if automated AI evaluation is actually working?

A: Look for stable agreement with human reviewers, low sensitivity to answer order, and consistent scores across repeated tests on the same inputs. If the judge’s output moves when presentation changes or drift appears after model updates, the evaluation control is no longer trustworthy enough for production use.

Q: How should appsec teams align LLM risk with NHI governance?

A: Appsec teams should align LLM risk with NHI governance by reviewing service accounts, API keys, and delegated access as part of the same control set. AI features frequently rely on machine identities to reach tools and data, so lifecycle, scope, and offboarding need to be governed together. Separate programmes leave the real exposure unowned.

Technical breakdown

Why LLM discovery changes the appsec control model

LLM discovery is the problem of identifying where models, prompts, tools, and AI-enabled workflows actually exist across the application estate. In practice, teams often know they have GenAI usage in development, but not where those components are embedded in production services, third-party integrations, or internal automations. That creates a blind spot for ownership, testing scope, and change control. Once AI behaviour can be triggered through ordinary application paths, traditional appsec inventories become incomplete unless they include AI-specific dependencies and execution points.

Practical implication: extend application inventories to include AI features, tool calls, and model dependencies before relying on test coverage.

How MCP expands the security boundary around AI-enabled apps

MCP, or Model Context Protocol, creates a standard way for AI systems to connect to tools and data sources. That interoperability is useful, but it also means a single weak integration can expose credentials, overbroad permissions, or unsafe tool access across multiple workflows. The key governance issue is not just whether the protocol works, but whether the connected tools are least-privileged, properly scoped, and observable at runtime. Without those controls, MCP can turn a local integration weakness into a wider operational exposure.

Practical implication: review MCP-connected tools as privileged integrations and apply least-privilege access, logging, and offboarding controls.

Why runtime validation matters more than static testing for GenAI

Static testing can still find implementation flaws, but it cannot prove that an AI-enabled application behaves safely under real prompts, tool calls, or chained interactions. Runtime validation is about checking what the system actually does when it handles live traffic, including whether it discloses data, invokes unauthorised tools, or drifts outside intended policy. For AI-enabled applications, that matters because the risk often appears only after inference begins and external context is added. Appsec teams need validation that covers behaviour, not just code state.

Practical implication: add runtime checks for tool use, data exposure, and policy drift to the normal appsec testing cycle.

Threat narrative

Attacker objective: The attacker objective is to abuse an AI-enabled application path to reach tools, data, or actions that were never meant to be exposed through the model workflow.

1. Entry occurs when an LLM-enabled application or MCP-connected workflow is introduced without complete discovery of its integrations and identities.
2. Credential or permission abuse follows when exposed secrets, overbroad API access, or weak tool authorisation let the AI path reach systems it should not control.
3. Impact occurs when the AI-enabled path is used to disclose data, invoke unsafe actions, or widen the blast radius across connected services.

Breaches seen in the wild

• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM discovery is now a governance control, not an inventory exercise. If teams cannot locate where GenAI functions, prompts, and tool calls exist, they cannot define test scope or account for ownership. That makes discovery the first control boundary for appsec in AI-enabled estates, especially where application logic and machine identities are intertwined. Practitioners should treat discovery as part of control design, not just documentation.

MCP creates a privileged integration layer that inherits the risk of every connected tool. The protocol itself does not create the problem, but it concentrates trust relationships between models, services, and data sources. That means permissions, secret handling, and auditability must be judged at the integration layer rather than the model layer alone. Practitioners should govern MCP like any other privileged access path, with stronger lifecycle and authorisation checks.

Static application testing is insufficient when the security question is behavioural. AI-enabled workflows can be syntactically valid and still operationally unsafe if they call the wrong tool, expose the wrong data, or follow the wrong context. Behavioural drift: the gap between what the application is built to do and what it actually does under live AI interaction. Practitioners should measure that gap continuously.

LLM and MCP risk is converging with NHI governance. Once AI features depend on service accounts, API keys, and delegated tool access, the control problem becomes one of non-human identity scope and lifecycle. That is where appsec, IAM, and NHI governance stop being adjacent disciplines and become a single operating model. Practitioners should align AI security reviews with machine identity controls, not leave them in separate programmes.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

LLM discovery will become a baseline control expectation for AI-enabled applications. The practical shift is from testing the application you think you shipped to governing the AI paths you actually operate. That means inventory, ownership, and runtime validation now sit alongside code quality as part of security assurance.

Machine identity discipline is the hidden dependency behind safe GenAI adoption. Once AI features rely on service accounts, tokens, and API keys, their risk profile starts to look like NHI governance rather than isolated appsec. Teams that leave those identities outside the AI review cycle will miss the main failure path.

Behavioural drift is the signal security teams should watch for. If an AI-enabled workflow starts making tool calls, returning data, or following context paths that were not in the approved design, the control boundary has already shifted. Runtime observation must therefore complement pre-release testing.

For practitioners

• Inventory AI-enabled application paths Map every production location where LLMs, prompts, tool calls, or MCP integrations exist, including third-party and internal services. Assign owners and define test scope for each path before treating it as covered by standard appsec tooling.
• Restrict MCP-connected privileges Treat each MCP integration as a privileged service path and limit its access to the minimum tools, datasets, and actions required. Review secrets, token scope, and offboarding so disconnected tools do not remain reachable.
• Add runtime behaviour checks Validate tool selection, data disclosure, and policy enforcement in live AI traffic rather than relying only on pre-production scans. Use runtime telemetry to spot when an AI-enabled path starts invoking unauthorised actions.
• Unify AppSec and NHI governance Bring service accounts, API keys, and delegated access for AI features into the same review cycle as application security testing. That prevents AI features from inheriting unmanaged machine identity risk.

Key takeaways

• LLM discovery and MCP exposure are turning AI-enabled application security into a governance problem that reaches beyond static testing.
• The main exposure is not the model alone but the privileged tools, secrets, and service identities that let AI workflows act in production.
• Security teams need inventory, least-privilege integration control, and runtime validation to keep AI behaviour inside intended boundaries.

Key terms

• LLM Discovery: LLM discovery is the process of locating where language models are used across applications, workflows, SaaS tools, and embedded integrations. It identifies model endpoints, retrieval layers, and connected tools so security teams can assign ownership, assess exposure, and enforce policy before testing or deployment.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Runtime validation: A control practice that tests how an AI system behaves while it is connected to real tools and data, rather than only reviewing configuration or design documents. It matters because agentic systems can appear safe on paper and still fail when prompted, chained, or given access to connected services.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management, including how AI-enabled systems inherit non-human identity risk. It is designed for practitioners who need to connect identity controls to broader security programmes.