Topic starter
19/08/2026 3:29 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Pynt: “The Next Big Thing in AppSec: LLM Discovery and Security Testing”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:12 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LLM discovery and testing are becoming the new AppSec baseline