LLM discovery and testing are becoming the new AppSec baseline

At a glance

What this is: Pynt argues that LLM discovery and security testing are becoming the next baseline for application security because AI systems now sit between users, tools, and APIs.

Why it matters: IAM, AppSec, and AI security teams need visibility into model usage, tool access, and context flows because unmanaged LLM integrations expand the attack surface without traditional controls seeing it.

By the numbers:

• 98% of respondents have already adopted or are in the process of adopting AI.
• 24% of organisations are currently onboarding MCP security tools while their MCPs already serve users.
• 55% of respondents rank API security as their top concern for 2026.

Context

LLMs are turning application security into a problem of hidden control planes, because the real risk now sits in the chain between prompts, tools, APIs, and output. Traditional AppSec assumes stable interfaces and predictable logic, but LLM-based systems can call tools, retrieve context, and expose data in ways that conventional scanning does not see.

For identity and access teams, the governance question is not whether an AI feature exists but whether it is discoverable, attributable, and constrained. Once an LLM can touch sensitive systems, the question becomes who authorised that access, what data it can reach, and how the organisation tests those pathways over time.

Key questions

Q: What breaks when LLMs are deployed without discovery first?

A: Security teams lose the ability to inventory where models sit, what data they touch, and which tools they can call. Without that map, testing becomes incomplete and policy enforcement lands on the wrong layer. The result is unmanaged exposure, because the organisation secures the visible application while the model quietly expands the attack surface behind it.

Q: Why do conversational interfaces increase application security risk?

A: They hide structured machine-to-machine actions behind natural language, which makes access paths harder to see and test. The model may call APIs, retrieve context, or reveal data without a fixed request pattern, so traditional scanners miss the real behaviour. Risk rises when human-like interaction is mistaken for low-risk user interface design.

Q: What are the signs that an LLM security program is failing in production?

A: Common warning signs include unexpected policy bypasses, sensitive data appearing in outputs, weak visibility into model behavior, and security controls that were only tested before launch. If teams are not monitoring for abnormal prompts, toxic outputs, or retrieval abuse, they will miss early indicators that the system is behaving outside its intended boundary.

Q: How should teams govern LLM APIs that can read data and invoke tools?

A: Treat them as privileged runtime systems, not passive software features. Set strict permissions, continuously validate behaviour after every change, and preserve evidence that the model stayed within its approved action scope. The security question is not just whether the model works, but whether its delegated access remains acceptable.

Technical breakdown

Why LLM discovery is the first control plane problem

LLM discovery is the process of mapping where models are embedded, what they connect to, and which data flows they influence. In practice, models appear inside copilots, SaaS integrations, workflows, and custom code, often without a central inventory. That creates a control gap similar to shadow APIs, but with a larger trust surface because the model can interpret input, select tools, and shape outputs. Security teams cannot test what they cannot find, and governance breaks down when the model estate is unknown.

Practical implication: Build an inventory of every model, agent, and embedded LLM path before attempting policy enforcement or testing.

How LLM testing differs from API testing

API testing checks structured requests against known contracts, while LLM testing has to probe semantic and contextual behaviour. The system can be coaxed into revealing data, ignoring instructions, or misusing tools even when the underlying API is nominally protected. That means the test target is not only the endpoint but the reasoning path from prompt to tool call to response. This is why prompt injection, data leakage, and tool abuse sit at the centre of LLM testing rather than classical injection patterns alone.

Practical implication: Test the full prompt-to-tool chain, not just the exposed API surface or model output.

Why context validation matters more than static rules

LLMs behave non-deterministically, so a one-time approval or rule set rarely survives real use. Context windows, retrieval content, and memory can all alter what the model sees and how it behaves at runtime. That makes guardrails a dynamic control problem, not a static configuration problem. When the model can change behaviour based on surrounding context, the security boundary moves from code review to continuous runtime observation and policy enforcement.

Practical implication: Use runtime guardrails and context controls to monitor what the model can see, retrieve, and act on in production.

Threat narrative

Attacker objective: Exploit the model’s trusted position in the application chain to extract data or trigger unintended actions through connected systems.

1. Entry occurs when an LLM is embedded into support, developer, or internal workflow systems without complete discovery or pre-deployment testing.
2. Credential and context abuse follows when the model receives access to sensitive data, memory, or downstream tools that were not tightly scoped.
3. Escalation happens when prompt injection, context poisoning, or tool misuse causes the model to reveal information or trigger actions beyond its intended role.
4. Impact is data exposure, unsafe system actions, or uncontrolled access through the application chain rather than the model alone.

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.
• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

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 an inventory discipline, not a tooling preference. The article is really describing a control-plane problem: security teams cannot govern what they cannot enumerate. In AI-enabled applications, discovery has to capture embedded models, shadow integrations, connected tools, and the data classes they touch. For IAM and AppSec teams, that means ownership and visibility are now prerequisite controls, not optional hygiene.

The new failure mode is context-driven privilege. An LLM may not hold a credential in the classic sense, but it can still inherit effective access through prompts, memory, retrieval, and tool permissions. That shifts governance from static authentication events to dynamic authorisation at inference time. The practitioner takeaway is simple: access decisions for models and agents must be evaluated at the moment of use, not only at onboarding.

Context-aware testing is the right label for the next AppSec baseline. The article correctly connects DAST, API testing, and LLM testing into one continuum because the attack surface is now semantic as well as technical. Context leakage gap: the control failure is not just exposed endpoints, but the absence of tested boundaries around retrieved content, tool calls, and model memory. Teams should treat this as a design issue in application governance, not just a scanner gap.

API security remains the anchor control even when the interface is conversational. The model is wrapping APIs, not replacing them, so the underlying risk often still lands in authentication, authorisation, and inventory management across machine-to-machine paths. That means AI security programmes that ignore API governance will miss the actual enforcement layer. Practitioners should align LLM governance with existing API and identity controls rather than building a separate silo.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: NHI Lifecycle Management Guide

What this signals

Context-aware testing is becoming the practical response to LLM sprawl. Teams that already have API testing in place now need to extend those controls to prompts, retrieval, tool calls, and outputs, because the attack surface has moved into the interaction layer. Security programmes that keep AppSec and AI testing separate will miss cross-boundary failure modes.

LLM governance starts with discoverability and ends with runtime enforcement. Once AI features sit inside business applications, the programme needs ownership, attribution, and control over what the model can see and do. That is the difference between a managed AI rollout and a shadow interface that can reach sensitive systems without meaningful oversight.

For practitioners

• Map every LLM entry point Inventory embedded copilots, agent workflows, SaaS integrations, and custom model calls so security teams can see where LLMs actually exist and what they connect to.
• Test the full prompt-to-tool chain Run adversarial tests across prompt injection, retrieval poisoning, tool misuse, and downstream API calls, because the real failure often appears after the model decides to act.
• Scope model access like a privileged service Treat model-connected tools and APIs as governed access paths, with explicit entitlements, narrow data exposure, and documented ownership for each integration.
• Move guardrails to runtime Pair pre-deployment review with runtime monitoring so changes in retrieved context, memory, or output behaviour are detected when the model is live.

Key takeaways

• LLM discovery is becoming a prerequisite for meaningful application security because models now sit inside workflows, integrations, and tool chains that traditional scanners do not fully see.
• The main security problem is no longer model presence alone, but the combination of context, connected APIs, and runtime behaviour that can be manipulated or misused.
• Teams that treat conversational interfaces as ordinary front ends will miss the access, data, and control paths that actually determine risk.

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.
• Context-Aware Testing: Context-aware testing is the practice of validating software, controls, or AI behavior using the real conditions in which they operate. It considers identity, permissions, data sensitivity, environment, and workflow state. In security and identity programs, it helps reveal failures that only appear when access, policy, or context changes during execution.
• Tool Abuse: Tool abuse occurs when an AI assistant is manipulated into making actions through connected APIs, plugins, or workflows that the user did not intend. The risk is not only incorrect output, but execution of legitimate systems with attacker-chosen inputs or destinations.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, agentic AI identity, and machine identity security through the industry's only accredited NHI security programme. It is a practical fit for practitioners responsible for access, tooling, and governance across modern identity programmes.