Prompt templates are code in AI gateways
Prompt templates are not copy. In an agent gateway, they are executable infrastructure: they combine user-controlled configuration, identity context, model instructions, and tool access. Treating them as harmless text is how a flow editor becomes a command-execution path.
On October 2, GitLab released critical patches for CVE-2026-90970 in the self-hosted GitLab AI Gateway. GitLab says an authenticated user with Duo Agent Platform access could escape a prompt template sandbox through a crafted flow configuration, resulting in arbitrary command execution on the gateway. The affected versions were 18.1.6 before 19.2.4, 19.3 before 19.3.2, and 19.4 before 19.4.1, and the CVSS score is 9.9. GitLab advisory
This is not a story about one vendor shipping one critical patch. It is a story about a new class of infrastructure that sits between developers, models, tools, secrets, and business systems.
The AI gateway is becoming the place where prompts stop being content and start becoming control flow.
Why this CVE matters beyond the patch
Most security programs already know how to reason about server-side template injection in web applications. If user-controlled input reaches a template engine and the sandbox fails, the attacker may cross from data into execution. CVE-2026-90970 brings that old lesson into an agentic setting.
The Cloud Security Alliance's analysis frames the trust boundary clearly: an attacker supplies a flow configuration, the gateway renders its prompt template, and the sandbox intended to contain that rendering fails. The same note observes that user-authored agent definitions, including flows and prompt templates, are executable inputs. Cloud Security Alliance
That distinction matters because the gateway is not just rendering a page. It is brokering AI-native features, authenticating users, routing model requests, and connecting agent workflows to code and operational context. GitLab's install documentation describes the AI Gateway as a combination of an AI Gateway service and the GitLab Duo Agent Platform service, with JWT-based authentication and separate key pairs for gateway and workflow services. GitLab AI Gateway docs
When that component is self-hosted, it often sits close to source code, developer identities, model provider credentials, logs, and network routes that security teams would never expose to an ordinary user-controlled template.
The hidden control plane in agent flows
Agent platforms are making it easy for teams to define reusable flows: gather context, choose a model, call a tool, transform output, open a merge request, update an issue, trigger a pipeline. That is useful. It is also a control plane.
The uncomfortable part is that many organizations still review these flows like configuration. A YAML file, a prompt template, or a natural-language workflow definition feels less dangerous than a plugin, CI job, or shell script. But the runtime does not care what the interface looked like. If a template is evaluated by a server process, and that process has credentials or network reach, the template is part of the trusted computing base.
The risk is amplified by the role of the gateway. It can become a privilege broker for model calls, tool access, workflow services, and identity assertions. A vulnerable gateway is not merely another web service. It is the component that decides which agent action gets represented as authorized work.
This is why the phrase "authenticated user" should not be comforting. In agentic systems, authenticated users include developers, automation owners, external contributors, compromised accounts, and service identities that may have permission to author or trigger flows. If the platform lets those identities supply executable templates, the threat model includes them.
The OWASP Agentic Top 10 lens
CVE-2026-90970 maps cleanly to several OWASP Agentic Top 10 (2026) risks.
ASI02, Tool Misuse and Exploitation, is the obvious one. The gateway turns agent definitions into actions. If the rendering layer can be exploited, the attacker is misusing the platform machinery that connects the agent to its tools.
ASI05, Unexpected Code Execution, is also central. The endpoint is not "the model said something wrong". The endpoint is command execution on a gateway host through a template sandbox escape.
ASI03, Identity and Privilege Abuse, shows up because the attack starts from legitimate platform access. The question is not only whether the user can log in. It is whether that user's authoring rights should be able to influence a server-side interpreter with gateway privileges.
ASI10, Rogue or Goal-Drifting Agents, is the operational layer. Once a gateway can execute unexpected code, the agent system can perform actions outside its intended task boundary while still appearing to move through approved platform components.
OWASP's September 2026 announcement also points in the right direction: agentic AI security is moving toward practical runtime enforcement through the Agent Control Standard and related guidance. The standardization signal is important because a prompt template sandbox is not enough by itself. OWASP GenAI Security Project
What security teams should change
The immediate step is simple: patch self-hosted GitLab AI Gateway deployments to 19.2.4, 19.3.2, or 19.4.1. GitLab says customers using GitLab-hosted AI Gateways are already protected, while self-hosted installations should upgrade immediately. GitLab advisory
The longer-term change is bigger: stop classifying agent templates as "just prompts".
Put templates under change control
Require review for agent flows that can alter code, run tools, reach secrets, or influence CI. Track author, approver, diff, and rollback path.
Assume the template sandbox can fail
Run template rendering in a narrow runtime with minimal filesystem, no ambient cloud credentials, restricted network egress, and disposable execution state.
Separate authoring from execution
A user who can define a flow should not automatically gain the gateway's operational privileges. Execution should require a scoped identity tied to the approved task.
Record the security-relevant chain
Capture the flow version, template hash, user identity, model call, tool call, outbound request, and file or command effects in one event trail.
Two extra checks are worth adding this week.
First, inventory every place your AI platform evaluates user-authored templates, prompt snippets, tool descriptions, agent skills, flow definitions, or workflow configuration. The answer will probably be larger than your security team expects.
Second, ask what the rendering process can reach if it breaks. If the answer includes source code, model provider keys, CI secrets, internal APIs, or production network routes, the renderer needs to be treated as a high-value execution service.
The practical test is blunt: if a template can change what an agent does, and the platform evaluates that template on a privileged server, the template belongs in your software supply chain and your runtime control plane.
The lesson for CISOs
AI gateways are becoming the choke point for enterprise agent adoption. They are where model access, identity, policy, telemetry, and tool execution converge. That makes them attractive control points. It also makes them attractive failure points.
CVE-2026-90970 is a reminder that agent security is not only about prompt injection in untrusted documents or malicious tool output. Sometimes the vulnerable prompt is the one your own platform accepts as configuration.
Security teams should keep using gateways. Centralizing model and agent traffic is still better than unmanaged agent sprawl. But the gateway has to be hardened like the system of record it is becoming: reviewed templates, constrained renderers, least-privilege execution identities, independent logs, and policy checks outside the agent loop.
The core shift is simple. Prompt templates are code. Agent flows are programs. AI gateways are production infrastructure.
Treat them that way before the next sandbox escape decides for you.