Topic starter
19/08/2026 3:33 pm
TL;DR: LLM discovery, MCP exposure, and testing gaps are turning AI-enabled application security into a broader governance problem, according to Pynt. Published research shows 98% of organisations are adopting LLMs into apps while only 24% have onboarded security tools, and the security model is shifting from static application testing to continuous discovery, access control, and runtime validation.
Editorial analysis by NHI Mgmt Group, based on content published by Pynt: “Pynt Blog: LLM Security Category”.
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.
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.
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.
Practitioner guidance
- Inventory AI-enabled application paths Map every production location where LLMs, prompts, tool calls, or MCP integrations exist, including third-party and internal services.
- 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.
- Add runtime behaviour checks Validate tool selection, data disclosure, and policy enforcement in live AI traffic rather than relying only on pre-production scans.
Bottom line: LLM discovery and MCP exposure are turning AI-enabled application security into a governance problem that reaches beyond static testing.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:15 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: LLM discovery and MCP security are becoming core AppSec issues