TL;DR: 98% of respondents have already adopted or are adopting AI, while 24% are onboarding MCP security tools after users are already in place and 55% rank API security as their top 2026 concern, according to Pynt's GenAI Application Security Report. The security problem is not model presence alone, but visibility, context control, and runtime testing across model, tool, and API chains.
NHIMG editorial — based on content published by Pynt: the GenAI Application Security Report, 2025
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every model touchpoint Discover internal copilots, SaaS-integrated models, workflow automations, and embedded model calls before setting policy.
- Test the full interaction chain Run adversarial testing across input, reasoning, retrieval, tool call, API, and output.
- Restrict delegated tool access Assign least privilege to every connector, database, and workflow an LLM can reach.
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
👉 Read Pynt's GenAI Application Security Report on LLM discovery and testing →
LLM discovery and testing: is your AppSec model keeping up?
Explore further
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.
A question worth separating out:
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.
👉 Read our full editorial: LLM discovery and testing are becoming the new AppSec baseline