GenAI app security is becoming an API and control-plane problem

At a glance

What this is: This research argues that GenAI has shifted application security toward API and control-plane governance, with LLMs and MCPs creating dynamic, tool-connected attack surfaces.

Why it matters: It matters because IAM, PAM, and application security teams now have to govern machine-to-machine actions, hidden privilege paths, and runtime dependencies that older controls were not built to see.

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.

👉 Read Pynt's GenAI Application Security Report on MCP, LLMs, and AppSec risk

Context

GenAI application security is no longer a lab exercise. When LLMs and MCPs sit inside production workflows, the problem shifts from isolated model risk to governance over tool use, data flow, and runtime decision paths. That creates a direct identity and access question because the system now delegates actions through APIs, services, and service-level credentials rather than only through human users.

The article’s core claim is that traditional AppSec tooling was built for fixed endpoints and predictable inputs, while GenAI creates dynamic, adaptive call chains that are harder to inspect and control. For IAM and NHI teams, the relevant question is how to govern the identities, permissions, and trust boundaries that let AI systems act across internal and third-party services.

In that sense, the starting position described here is increasingly typical, not exceptional. Organisations are moving faster than their control models, which means visibility and authorisation must now keep pace with application design.

Key questions

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. MCP determines how the agent reaches the system, while GraphQL determines what the agent can understand and query. Treat the schema as part of the authorization boundary, review field exposure by business sensitivity, and restrict composition paths that let an agent assemble more context than the workflow requires.

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. If those identities are broad or reusable, the AI system inherits standing privilege. The result is more hidden access, wider blast radius, and weaker accountability.

Q: Where do traditional AppSec tools fail in GenAI environments?

A: They fail when security depends on runtime behaviour rather than static code paths. WAF, SAST, and DAST can still detect some issues, but they do not fully show which model, tool, or API call sequence was executed. That gap leaves hidden dependencies and unauthorised actions outside normal test coverage.

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.

Technical breakdown

Why MCP changes the application control plane

Model Context Protocol, or MCP, is a standard way for LLMs to connect to tools, APIs, and data sources. That matters because once an AI workflow can select tools at runtime, the control plane shifts from code paths written by developers to decision paths executed by the model plus its orchestration layer. In practice, every connector becomes a governed trust relationship, and every runtime call can carry business, data, and security consequences. The architecture is powerful, but it also makes the boundary between application logic and external action much less visible.

Practical implication: teams need explicit governance for MCP servers, tool scopes, and the identities used to call downstream systems.

Why legacy AppSec struggles with GenAI workflows

Traditional application security controls assume stable endpoints, defined request patterns, and known execution paths. GenAI breaks those assumptions because prompts, retrieved context, and tool outputs can change the call graph in real time. WAFs, SAST, and DAST still matter, but they often miss the runtime relationships that determine whether an AI workflow can query, create, modify, or exfiltrate data. The real challenge is not only injection risk, but invisible dependency chains that make validation incomplete unless you can observe the full sequence of model, tool, and API interactions.

Practical implication: add runtime discovery and call-chain visibility before relying on static testing alone.

How AI-driven systems create NHI governance pressure

Every AI workflow that calls APIs relies on non-human identities such as service accounts, tokens, and secrets. If those credentials are broad, long-lived, or shared across environments, the AI layer inherits excessive privilege and the blast radius grows quickly. This is why GenAI application security intersects directly with NHI governance. The issue is not just whether the model is safe, but whether the credentials and authorisations behind it are constrained enough for ephemeral, task-scoped use. That is a classic identity problem in a new execution model.

Practical implication: map AI workflows to specific NHI credentials and reduce standing privilege wherever the model can act.

Threat narrative

Attacker objective: The attacker aims to use the AI workflow’s delegated trust to reach systems and data that should never have been exposed through that path.

1. Entry occurs when an attacker influences a GenAI workflow through a prompt, compromised connector, or abused third-party MCP server.
2. Escalation follows when the workflow uses over-broad service credentials or hidden tool permissions to reach internal APIs and data stores.
3. Impact occurs when the attacker turns the AI system’s delegated access into data exposure, malicious actions, or unauthorised system changes.

NHI Mgmt Group analysis

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.

AI application security now depends on NHI discipline: GenAI systems are only as safe as the service accounts, tokens, and secrets behind them. When AI workflows can invoke APIs dynamically, broad credentials become de facto delegated authority, which turns secrets management and privilege scope into first-order control issues. Practitioners should see every AI connector as an NHI governance problem with application consequences.

Controlled acceleration is the right market signal, but it requires visibility first: The article’s claim that innovation will accelerate only holds if organisations can observe what AI systems actually do. That aligns with broader industry movement toward runtime discovery, policy enforcement, and auditability. The named concept here is AI control-plane sprawl: the rapid multiplication of hidden tool paths, permissions, and dependencies around GenAI workflows. Teams that do not map these paths will lose governance faster than they gain productivity.

Traditional AppSec is being forced into a runtime model: Static testing still has value, but it cannot fully describe systems that generate their own request chains. That pushes the market toward continuous validation, policy-based authorisation, and stronger identity signals for machine actions. The practical conclusion is that AppSec, IAM, and platform teams now share responsibility for the same runtime trust boundary.

Developer freedom is narrowing because abstraction has a security cost: The article captures an important structural shift. As more logic is delegated to models and orchestration layers, developers see less of the execution path and therefore less of the real risk. The implication for practitioners is clear: governance must become more explicit as systems become more autonomous in how they assemble and call services.

What this signals

AI control-plane sprawl is the right shorthand for what this market is creating. As GenAI workflows spread across internal and third-party tools, organisations need a way to track which identities, permissions, and data paths each workflow depends on. That makes runtime discovery and policy enforcement more important than another layer of static testing.

The most immediate programme impact is that IAM, AppSec, and platform teams now share the same trust boundary. For identity teams, the practical task is to reduce standing privilege in service accounts used by AI connectors and to align access scope with the specific task the workflow performs.

This also raises the bar for auditability. If a workflow cannot be tied back to a named machine identity and a clear action trail, the organisation will struggle to explain or contain misuse. That is where the security value of visibility begins to exceed the value of speed.

For practitioners

• 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. This makes delegated access reviewable instead of implicit.
• 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. Treat any reusable access as standing privilege.
• 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. Without runtime visibility, investigators cannot reconstruct AI-driven misuse or prove that controls worked.
• Apply NHI rotation and revocation discipline to AI connectors Set short lifetimes for secrets used by GenAI integrations and revoke them when workflows, vendors, or environments change. Pair rotation with environment-bound scopes so a leaked credential cannot be reused broadly.

Key takeaways

• GenAI application security is shifting from code-centric review to governance over tool use, runtime actions, and delegated machine identity.
• The scale of adoption is already clear, but the control model is lagging, which makes visibility and least privilege the decisive issues.
• Teams that map AI workflows to specific credentials, scopes, and audit trails will be better positioned to manage the new control plane.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• GenAI Code Security: GenAI code security is the discipline of governing code produced by generative AI so that it is not only functional, but also safe to ship. It combines model evaluation, workflow verification, remediation prioritisation, and policy controls around where AI-generated code is allowed to enter production.
• Control-plane sprawl: Control-plane sprawl is the condition where identity, device, privileged access, and provisioning are managed in separate systems with weak policy coordination. It usually creates duplicated administration, inconsistent enforcement, and slower offboarding because no single workflow owns the whole lifecycle.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

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.

👉 Pynt's full report covers the survey data, control priorities, and the security trade-offs behind GenAI adoption.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for teams that need to control machine access. It gives practitioners a common baseline for governing the identities that AI systems, services, and workflows depend on.