GitLab AI Gateway CVE prompts fresh audits of AI agent permission enforcement

The flaw

A post published on dev.to on October 6, 2026 describes a critical vulnerability in GitLab's AI Gateway: CVE-2026-90970, carrying a CVSS score of 9.9, which lets a logged-in user with agent platform access execute commands on the gateway itself. The author writes that the advisory is the kind most people skim past — until they pause and consider what their own agent infrastructure actually enforces.

An audit of the author's own agent setup

The author, who identifies himself as Rohit, founder of a sandbox company called Krova Cloud, says his team runs an internal AI agent that can read logs, query internal APIs, open pull requests and restart services when they misbehave. The agent acts through a small internal gateway service that translates model tool calls into real actions. The gateway had no inbound exposure — internal DNS only, behind a VPN — and that, he says, was the entire security argument.

When he went looking for the same class of bug — command execution reachable by an agent session without proper authorization — two assumptions nearly ended the audit early. The first was that the risk was purely about network exposure; he confirmed there was no route in from outside the VPC and almost closed the investigation. The second was that a permissions.yaml file mapping agent roles to allowed tools must be enforced somewhere downstream. It was not.

Where enforcement actually lived

Permission filtering ran in the orchestration layer, the code that decides which tools to offer the model in a given session. If a role lacked access to a tool such as restart_service, the tool simply never appeared in the list sent to the model. The gateway's execution endpoint — the component that actually runs commands — performed no independent checks and trusted that filtering had already happened upstream.

The gap became reachable through retry logic. When a tool call timed out, a retry handler resubmitted the call directly to the execution endpoint to reduce latency, skipping the permission-aware orchestration path entirely and carrying the shared service-account credentials.

In effect, the permission model filtered what the model was offered rather than authorizing what the gateway executed, and the component doing the filtering followed the model's instructions instead of policing them. A compromised, confused or merely inventive agent session could, via the retry path, run anything the shared service account could — far beyond the intended scope of restarting one worker.

The fix

The team made two changes. First, enforcement moved into the execution endpoint itself: a single function checks role permissions and validates every argument against strict allowlist patterns, and every path into execution, retries included, now passes through it.

Second, the standing shared credential is gone. Each agent task now runs in its own short-lived, disposable sandbox VM with outbound-only networking and no reach into internal systems. This is where the post turns commercial: the author founded Krova Cloud, a sandbox provider, and his claims that this arrangement came out roughly 93% cheaper than E2B and 95% cheaper than Modal are his company's own comparison figures, not independently verified. The architectural point stands on its own either way.

Why it matters

The post's lessons generalize. A permission list consulted only upstream and then trusted downstream works as guidance, not enforcement; nothing at the execution layer is obliged to honor it. Retry handlers, fallbacks and fast paths are precisely where authorization quietly stops applying, because they bypass the layers where checks live. And a system that is not internet-facing still leaves open the question of what a session can do once it reaches the execution layer by any route. As AI agents acquire real credentials and real tool access, someone else's critical CVE is a cheap prompt to audit the paths into your own systems.