Gemini Cyber: Agent control for security teams

Google has introduced Gemini 3.5 Flash Cyber, a specialized model for security tasks. According to Google, it is paired with the CodeMender code-security agent and is meant to show that successful cybersecurity applications need more than a model: they need orchestrated agent infrastructure.

What changes

Alongside Gemini 3.6 Flash and 3.5 Flash-Lite, Google emphasizes three operational metrics: token efficiency, latency, and quality in agentic workflows. For 3.6 Flash, Google cites 17 percent fewer output tokens than 3.5 Flash on the Artificial Analysis Index; 3.5 Flash-Lite is described as reaching 350 output tokens per second. For security teams, Gemini 3.5 Flash Cyber is the more relevant announcement because Google explicitly positions it together with CodeMender as an agent setup.

The Vertex AI documentation also shows that model selection is increasingly a platform-management task. Companies choose not just one model, but a model family, version, operating environment, access path, and cost boundary.

Why it matters

Security agents are not ordinary chatbots. They read code, logs, tickets, policies, and sometimes production-adjacent artifacts. They can comment on pull requests, prioritize findings, or suggest fixes. That increases value, but also raises the risk of wrong tool calls, missed context boundaries, and indirect prompt injection.

OWASP therefore lists prompt injection as a core LLM risk. The BSI also treats AI as a security-relevant topic for companies and organizations. The sober conclusion is clear: specialized models do not replace governance. They increase the need for clear control.

DACH perspective

Before productive use, DACH companies should give a cyber agent an operating profile: permitted repositories, data classes, write permissions, human review, model version, logging, stop criteria, and cost limit. The separation between analysis and action is especially important. An agent may find vulnerabilities; whether it changes code, closes tickets, or triggers deployments is a separate approval decision.

A pragmatic starting point is a controlled AppSec pilot with a small number of repositories, a clear human-in-the-loop rule, and measurable criteria: less manual triage, fewer false positives, traceable recommendations, and no unreviewed changes in the production path.