Notifications
Clear all
Topic starter
19/08/2026 3:35 pm
TL;DR: GenAI adoption is already embedded in engineering workflows, with Pynt's 2025 survey of 250 engineering and security leaders finding 98% of organisations are adopting GenAI tools and 55% now rank API security as their top AppSec priority. The underlying issue is not model novelty but the new control plane created by LLMs and MCPs, where hidden tool calls expand attack surface faster than traditional AppSec can govern.
NHIMG editorial — based on content published by Pynt: The GenAI Application Security Report
By the numbers:
- 98% of organisations are adopting GenAI tools and integrating them into products and workflows.
- Only 2% said security risks stopped them from adopting GenAI tools.
Questions worth separating out
Q: How should security teams govern AI agents that access APIs through GraphQL and MCP?
A: Security teams should govern the agent, the transport, and the schema as one access path.
Q: Why do GenAI applications increase NHI risk?
A: GenAI applications increase NHI risk because they rely on service accounts, tokens, and secrets that can be used by models and orchestration layers at runtime.
Q: Where do traditional AppSec tools fail in GenAI environments?
A: They fail when security depends on runtime behaviour rather than static code paths.
Practitioner guidance
- Map every GenAI workflow to its downstream identities Inventory the service accounts, tokens, and API keys used by LLM and MCP-enabled workflows, then tie each one to a named owner and approved business function.
- Constrain MCP server privileges to task scope Review each third-party and internal MCP server for over-broad tool access, then reduce permissions to the minimum set required for the workflow.
- Add runtime visibility to GenAI call chains Instrument model, tool, and API interactions so security teams can see which actions were requested, approved, and executed.
What's in the full report
Pynt's full report covers the operational detail this post intentionally leaves for the source:
- Survey methodology across 250 engineering and security leaders, useful if you need to benchmark the findings internally.
- Breakdown of how organisations are using third-party MCP servers versus home-built implementations.
- Priority ranking of AppSec investment areas for 2026, including API security and related control choices.
- The report's full discussion of how developer autonomy is changing as GenAI tools take on more runtime decision-making.
👉 Read Pynt's GenAI Application Security Report on MCP, LLMs, and AppSec risk →
GenAI app security is becoming a control-plane issue for teams?
Explore further
19/08/2026 4:16 pm
MCP is becoming the missing control plane for GenAI governance: The article is right to frame MCP as infrastructure, not just integration. Once tool selection and context passing happen at runtime, governance must move from static app review to control of the tool path itself. That means security teams should treat MCP servers as privileged execution surfaces, not simple utilities.
A question worth separating out:
Q: How can organisations measure whether GenAI code security controls are working?
A: Track the proportion of AI-generated changes that fail security checks, the time to remediate vulnerabilities introduced by AI output, and the share of high-risk code paths covered by mandatory review. If those numbers are flat or worsening as AI usage grows, the governance model is not keeping pace.
👉 Read our full editorial: GenAI app security is becoming an API and control-plane problem
