LLM discovery and testing are becoming the new AppSec baseline

At a glance

What this is: This is Pynt's analysis of how LLMs and AI agents are expanding the application attack surface, with discovery and context-aware testing positioned as the next security baseline.

Why it matters: It matters because identity, access, and data exposure now extend into model prompts, tool calls, and delegated workflows, creating governance gaps that classic AppSec and IAM teams must jointly address.

By the numbers:

• 98% percent of respondents have already adopted or are in the process of adopting AI, with only 2% resisting.
• 24% percent of organizations are currently onboarding MCP security tools while their MCPs already serve users.
• 55% percent of respondents rank API security as their top concern for 2026, surpassing LLM-specific tools and traditional AppSec combined.

👉 Read Pynt's GenAI Application Security Report on LLM discovery and testing

Context

LLMs are no longer experimental add-ons. They now sit between people and business systems, pulling context from documents, APIs, and workflows while sometimes taking action on behalf of users. That creates a new application security problem because the interface is semantic and dynamic rather than fixed and deterministic.

For IAM and security teams, the governance issue is not only what the model can say, but what it can reach, trigger, or reveal through connected tools and delegated access. In practice, LLM exposure overlaps with secrets, API authorisation, workload identity, and non-human identity control, which means discovery must extend beyond traditional asset inventories.

Key questions

Q: How should security teams govern LLMs that can call tools or run code?

A: Security teams should govern them as privileged workloads, not as chat interfaces. Every tool call needs server-side authorization, schema validation, and a dedicated identity with minimal scope. If a model can influence code execution, treat that path like a production admin channel and apply least privilege, logging, and runtime isolation.

Q: Why do LLMs create more risk than ordinary application workloads?

A: LLMs do not just process input, they interpret natural language, retrieve context, and may trigger actions based on that interpretation. That means a malicious prompt can become an execution path, especially when the model has access to data stores, tools, or business systems. Identity scope and runtime policy therefore matter more than static perimeter controls.

Q: What breaks when teams discover AI after deployment instead of before?

A: When discovery comes late, teams lose visibility into where models sit, what data they touch, and which systems they can influence. That makes policy enforcement, testing, and incident response incomplete. The result is unmanaged exposure across prompts, connectors, and API access paths that security never intended to approve.

Q: Should LLM security be managed separately from API security?

A: No. LLM security and API security are now tightly coupled because most models sit on top of existing services. Teams should manage them together, with shared visibility into identity, secrets, authorisation, and runtime behaviour. Separating them leaves the real trust chain ungoverned.

Technical breakdown

Why LLM discovery is the starting point for control

LLM discovery is the process of finding where models, copilots, embeddings, and retrieval layers actually exist across apps, SaaS, and internal workflows. Unlike standard web assets, LLMs can be embedded in scripts, plugins, low-code automations, or third-party services without a visible control plane. That makes discovery a prerequisite for testing because teams cannot govern prompt flows, tool access, or data exposure if they do not know where model interactions occur.

Practical implication: Map every model touchpoint before attempting policy, testing, or runtime guardrails.

How context-aware testing differs from API testing

Traditional API testing assumes a fixed schema and predictable request-response behaviour. LLMs are different because prompts, system instructions, retrieved context, and tool outputs interact probabilistically. Context-aware testing therefore probes instruction hierarchy, retrieval poisoning, prompt injection, data leakage, and unsafe tool invocation as a single chain. The important shift is that the model is not isolated from the application. It becomes part of the application logic and can amplify upstream identity or access mistakes.

Practical implication: Test the full input-to-output chain, not just the model prompt or the API endpoint in isolation.

Why tool and plugin abuse is an identity problem as much as an AppSec problem

When an LLM can call tools, it inherits delegated access to APIs, databases, ticketing systems, or production workflows. That means the security boundary is no longer just the model response. It is the authority granted to the non-human process acting through the model. If those permissions are broad, long-lived, or poorly attributed, the LLM can become a disguised access broker. In identity terms, this is a form of over-privileged non-human access with conversational triggers rather than traditional login events.

Practical implication: Treat tool-enabled LLMs as governed identities with least privilege, auditability, and tight access scope.

Threat narrative

Attacker objective: The attacker aims to turn the model layer into a trusted but manipulable path to sensitive data, systems, or privileged actions.

1. Entry begins when a user, workflow, or embedded integration introduces an LLM into a business process with access to context, tools, or APIs.
2. Escalation occurs when prompt injection, retrieval poisoning, or delegated tool use causes the model to reveal data, bypass instructions, or issue unintended API calls.
3. Impact follows when the model exposes sensitive information, performs harmful actions, or becomes a gateway into connected systems and business data.

NHI Mgmt Group analysis

LLM discovery is now a governance control, not an inventory exercise. The article correctly frames discovery as step zero because hidden model calls create blind spots in security ownership, data flow, and access review. For identity teams, that matters because model-enabled workflows often sit outside normal application onboarding and offboarding paths. The practical conclusion is that LLM discovery belongs in asset governance, not just AppSec scanning.

Context-aware testing exposes a new kind of trust boundary. The important issue is not whether an LLM can be made to fail a prompt test, but whether the surrounding chain can resist instruction override, retrieval poisoning, and unsafe delegation. That makes OWASP Agentic AI Top 10 thinking and NIST AI RMF style governance relevant where models can act, not just answer. Teams should assess the full reasoning chain before they approve production use.

AI-driven workflows create a non-human identity problem even when the interface looks human. Once a model can call tools, it behaves like a governed runtime identity with delegated privileges and audit obligations. That makes over-privileged connectors, long-lived API keys, and unclear accountability the real exposure, not the chatbot surface itself. Practitioners should treat model-connected systems as identities with lifecycle control requirements.

API security remains the hidden dependency behind most LLM risk. The article's emphasis on APIs is accurate because models usually wrap existing services rather than replace them. That means weak authorisation, broad service account scope, and poor secret handling still drive the blast radius. The named concept here is context-perimeter drift: security controls are moving from fixed endpoints to conversational, tool-mediated interactions, and governance has not kept pace. Teams need to align runtime controls with that shift.

What this signals

Context-perimeter drift: security programmes are moving from controlling fixed APIs to governing conversational and tool-mediated workflows, which means existing application controls will miss the real decision points unless discovery expands to model, connector, and retrieval layers.

The practical signal for teams is that AI adoption is no longer the issue. The control problem is whether model-connected systems are mapped, authorised, and monitored with the same discipline as privileged human and non-human access.

A useful reference point is the The 52 NHI breaches Report, because the same lifecycle failures that exposed service accounts now reappear in agentic workflows when permissions, secrets, and offboarding are not tightly governed.

For practitioners

• Inventory every model touchpoint Discover internal copilots, SaaS-integrated models, workflow automations, and embedded model calls before setting policy. Include model-adjacent tools, retrieval layers, and third-party services that can silently invoke LLM APIs.
• Test the full interaction chain Run adversarial testing across input, reasoning, retrieval, tool call, API, and output. Look specifically for prompt injection, context poisoning, and unintended tool invocation rather than treating the model as a standalone asset.
• Restrict delegated tool access Assign least privilege to every connector, database, and workflow an LLM can reach. Replace broad service account permissions and static secrets with tightly scoped, auditable access.
• Add governance to AI-enabled workflows Put ownership, approval, logging, and review into the same process that governs human and machine access. If an LLM can act on a system, its permissions should be reviewed like any other privileged non-human pathway.

Key takeaways

• LLMs are becoming part of the application control plane, which makes discovery a prerequisite for secure use.
• Context-aware testing matters because the model, its tools, and its connected APIs form a single attack surface.
• Once an LLM can act, its delegated access must be governed like a non-human identity with least privilege and auditability.

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.
• Runtime-Aware Testing: Runtime-aware testing evaluates how an application behaves while it is executing, rather than only inspecting code or dependencies at rest. It helps identify reachable, exploitable issues by observing actual data flow, authentication behaviour and route exposure in staging or production-like environments.
• Tool-Connected LLM: An LLM that can do more than generate text because it is wired to external systems such as email, calendars, ticketing, or CRMs. The security risk changes materially once the model can trigger side effects, because prompt manipulation can become access abuse.
• Context-Perimeter Drift: Context-perimeter drift describes the shift from protecting fixed technical boundaries to protecting conversational and tool-mediated interactions. It captures the gap that appears when security controls remain endpoint-centric while business logic, data access, and privileged actions move into model-assisted workflows.

What's in the full report

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

• Step-by-step guidance for LLM discovery across copilots, SaaS embeds, low-code workflows, and hidden model calls
• Test categories for prompt injection, data leakage, context injection, and tool or plugin abuse
• The report's DAST to API to LLM testing progression and how to adapt it for runtime observation
• Practical context-aware testing examples for teams building AI-native application security programmes

👉 Pynt's full report covers the discovery workflow, testing categories, and context-aware security model in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It is suitable for practitioners who need a stronger control model for AI-enabled access and delegated workflows.