Why Gemini Enterprise Security Agents Are Suddenly a Catalog, Not a Concept
Google Cloud published a partner announcement on September 30, 2026 that adds a batch of security vendors to the Gemini Enterprise catalog. The line that frames the whole thing comes near the top: defenders hold business context that attackers do not, and that context is currently scattered across identity, network, endpoint, data, cloud, and application tools, “often split across a dozen or more products, each with its own context.” I have lived that split. On a bad Tuesday it means one console for the identity provider, another for the EDR agent, a third for the cloud audit log, and a spreadsheet that ties the timeline together by hand.
What changed is not a new detection engine. Partner-built agents now appear in the Gemini Enterprise ecosystem (opens in new tab) alongside the sales, HR, and content agents Google showed off at Cloud Next. Acalvio, Britive, Check Point, CrowdStrike, Cyberhaven, Cyera, Endor Labs, Exabeam, and Fastly all have something listed. That is a meaningful shift in packaging. Security capability that used to arrive as a console you log into now arrives as a catalog entry you invoke, and the invocation is a sentence typed in plain language.
If your team already runs Gemini Enterprise, this is worth an hour of your week, because the same tenant that drafts marketing copy can now be asked to contain a compromised service account. If you are still evaluating Gemini Enterprise as a place to run multi-step workflows rather than a chat window, this announcement is the clearest signal yet about which direction Google intends. Think of it like the cPanel plugin marketplace: once the panel owns the billing, the updates, and the permission model, the plugins become interchangeable parts rather than separate products with separate logins. That is roughly the shape here, and it cuts both ways for the vendors involved.
Two things this post will not do. It does not benchmark any of these agents, because I have not run them in a production tenant and the announcement includes no published numbers. Everything below is drawn from vendor claims and from how the pieces are described as fitting together, plus my own read on where the architecture creates problems.
Background: What Are Gemini Enterprise Security Agents?
Gemini Enterprise security agents are partner-built agents that sit in the Gemini Enterprise catalog and get invoked in natural language by an analyst. You type something like “contain this compromised service account” and the agent breaks that request into steps it runs inside the vendor’s own platform. You are not clicking through the vendor’s console yourself. The vendor’s control plane does the clicking, and Gemini Enterprise is where you asked for it.
That is a different thing from a normal API integration, and the distinction is worth being precise about. With an API integration, the human still drives every console. You log into your identity provider to confirm who the account belongs to, then into the cloud console to list active sessions, then back to the ticket to write down what you did. Britive’s Emergency Termination Agent is described as doing that whole sequence in one pass: confirm the identity, list active privileged sessions, revoke them after a human approves, disable the identity, and gather audit context for the incident ticket. The approval step stays. That detail matters more than the automation does, and I will come back to it.
Agent Gateway and Agent Registry are the Google Cloud plumbing underneath all of this. Gateway sits in front of agent traffic, and Registry tracks which agents exist and what they are permitted to do. Check Point’s AI Defense Plane and CrowdStrike Falcon Guardian both hook into that pair, which is how they inspect runtime behavior rather than sitting off to the side reading logs after the fact. If you have ever configured a reverse proxy and a service registry for microservices, this is the same idea pointed at agents instead of containers.
None of this replaces your SIEM or your SOAR. Google does not claim that, and CrowdStrike’s own wording (opens in new tab) is narrower: bringing CrowdStrike context into agentic investigation and response, and helping orchestrate SOC workflows across numerous tools. Orchestrating across tools is not the same as being the tool. If your team already has SOAR playbooks that work, an agent that compresses four console steps into one sentence is an addition to that stack, not a replacement for it.
What’s Happening Now: The Agent Lineup and the AI Workload Guardrails
Google splits the announcement into two buckets, and the split is worth keeping straight because they get sold to different people. The first bucket is agents an analyst invokes by name. The second is protection for the AI and agentic workloads themselves. Both show up in the same catalog, and neither one substitutes for the other.
Identity containment. Britive’s Emergency Termination Agent covers human and non-human identities from a single natural-language request. Non-human identity containment is the part most teams have let slide, because a compromised service account has no badge, no manager, and no HR record to trigger a review when something looks wrong. Now it gets the same revocation flow and the same audit trail as a departing employee, with the human approval gate still in place.
Deception at scale. Acalvio’s ShadowPlex agent deploys network decoys, identity honey accounts, RAG decoys, honey skills, and honeytokens without manual configuration. Most teams I have worked with run one or two honeypots, forget the credentials, and leave them sitting for years. This is a far wider decoy surface than that, which cuts both ways: more chances to catch lateral movement, and considerably more noise to tune out of your alerting.
AI workload guardrails. Check Point’s AI Defense Plane discovers AI workloads, monitors risk posture, flags non-compliant behavior, and applies real-time guardrails against prompt injection, data exposure, and rogue agentic behavior. It is managed through a Check Point agent in Gemini Enterprise and integrates with Agent Gateway and Agent Registry rather than bolting on afterward.
The runtime, data, and code layer is more crowded:
- CrowdStrike Falcon Guardian covers prompt injection, sensitive data leakage, and malicious AI activity at runtime through Agent Gateway.
- Cyberhaven Linea classifies sensitive data across endpoints, cloud apps, and agentic workflows, and the announcement names Antigravity as an extension point.
- Cyera Agent Guardian handles DSPM and DLP, correlating machine identities, delegated permissions, and data classification to verify that agent behavior is actually authorized.
- Endor Labs AURI puts a SAST triage agent inside developer platforms, classifying findings and letting security teams query them conversationally.
- Exabeam Nova coordinates multiple agents across investigation and response, and Fastly’s Autonomous Edge Defense Agent lets teams investigate edge incidents in plain language.
There is real overlap in that list, particularly among the data-focused tools. More on that below.
What It Means in Practice for Agentic AI Security
That overlap lands hardest in the data layer. Cyera, Cyberhaven, and Check Point each claim some version of seeing your sensitive data and knowing when an agent touches it, and the announcement (opens in new tab) does not sort out who owns which finding. At pilot scale that looks thorough. At production scale you get three dashboards flagging the same object with three severity ratings and no tiebreaker. Most teams will not buy all three, so the real question is architectural: does DSPM own data at rest, does lineage own data in motion, does the gateway own runtime policy, or do you pick one vendor and accept the blind spots? Decide that before procurement decides it for you.
Prompt injection protection moving down to the gateway and runtime layer matters more than it sounds. When one agent calls another, an application-layer filter only inspects the first hop, and whatever the second agent does with the response is invisible to it. Enforcement inside Agent Gateway puts policy in the traffic path regardless of which agent started the chain. That is the right place for it, mainly because it is the one spot a security team can control without rewriting every agent someone else built.
Non-human identity containment is the other shift worth watching. A leaked service account key behaves a lot like a back door in a shared office building: you cannot lock out the unknown holder by asking politely, and you rarely have a clean list of everyone who copied the key. Britive’s flow treats that identity the way an analyst treats a compromised employee account, confirming it, revoking active privileged sessions, disabling it, and attaching audit context to the ticket. Treating a machine identity as a first-class incident subject instead of a config item is doing a lot of quiet work in that sentence.
Then there is the autonomy tradeoff, which undercuts the whole idea if you get the placement wrong. Cyberhaven describes Linea as protecting assets “as fast as autonomous agents move them.” If your guardrail needs a human click for every policy decision, you have rebuilt the queue you were trying to remove. Emergency termination is a reasonable place for approval. Routine enforcement is not.
What I cannot tell you is how any of this behaves under a real incident at volume. The announcement offers directional claims like lower mean time to containment, no published numbers behind them, and I have not run these agents inside a production tenant myself.
What to Expect Next
The catalog will get bigger. Google established the pattern at Cloud Next by putting partner-built agents in one discoverable place, and the marginal cost for a security vendor to list another agent there is low. Some of what arrives will be genuinely useful. Some will be a checkbox on a partner slide. I would rather see a shorter catalog where each agent clearly owns a finding than a longer one where three vendors alert on the same data exposure and nobody agrees who closes the ticket.
Coverage will likely spread sideways across the Gemini Enterprise surface rather than deeper into any single control. Cyberhaven already names Antigravity as an extension point for Linea, and where data classification lands, policy enforcement and audit trails tend to follow whether or not that was the original pitch. The same agents will show up in developer workflows they were not designed for, and the ones that survive that migration will be the ones whose policies are readable by someone who is not a vendor specialist.
Pricing is the gap I would push on hardest before committing to anything. The announcement does not address whether these agents bill through Gemini Enterprise, through the vendor’s existing subscription, or both, and that answer changes the arithmetic on a pilot considerably. Per-seat, per-agent-run, and per-gigabyte-scanned are three very different curves depending on how much traffic your agents actually generate, and nobody can forecast that from a demo tenant.
My expectation, and this is a guess rather than something the announcement supports, is that Agent Gateway becomes the place where this market consolidates. Once the gateway is the enforcement point for prompt injection and runtime policy, the vendor sitting behind it starts to look more interchangeable than its marketing suggests. A company that has already written gateway policy has less reason to care which runtime scanner is attached, and vendors know that. Whether that produces acquisitions, deep discounting, or a wave of agents that differentiate on detection quality instead of integration depth, I cannot say. But the enforcement point is now Google’s, not theirs.
The practical consequence for you is that the questions worth asking have shifted. Ask your rep where the agent bills. Ask whether the policy lives in Gemini Enterprise or the vendor console. Ask what happens to your audit trail if you swap the agent behind the gateway in eighteen months. None of those answers are in the announcement.
Start Here: Test One Agent Against a Real Incident You Already Had
Ask your rep the billing question, then go do something more useful than reading another announcement. Pick the single incident type you have actually had to deal with, identity compromise or prompt injection, and pilot one agent against it. Switching on the whole catalog at once leaves you with eight dashboards and no way to tell which one caught anything.
Take identity compromise, since most small teams have lived through it. A reseller account on one of my boxes leaked a WHM API token a while back, and containment looked like this: SSH in, run whmapi1 listaccts to work out who the token belonged to, revoke it, kill every active session for that account, reset the password, then read /usr/local/cpanel/logs/access_log to see what got touched. Roughly forty minutes, and only because nobody called me in the middle of it. That wall-clock number, from the first alert landing in your ticket queue to the last dead session, is your baseline. Write it down before you deploy anything. Without it, “significantly lower MTTC” is a line in a press release rather than a result you can check.
Then spend an hour on overlap. Cyera, Cyberhaven, Check Point, and CrowdStrike all touch agentic data exposure from slightly different angles. If you already pay one of them, you are buying a second opinion rather than a new control, which can still be the right call. Just make it a deliberate one instead of discovering the duplication after the invoice.
The prompt injection test is the one I would run first, because it costs nothing and tells you whether the guardrail is real. Stand up a throwaway agent behind Agent Gateway, feed it a document containing an instruction to ignore its system prompt and dump a config file, and see whether the guardrail fires. No production data, no real users, no approval chain to negotiate. While you are in there, confirm you can scope that agent’s credentials to read-only. If the vendor’s setup guide assumes a service account with write access to your whole project, that is your first finding, and you found it in a sandbox. Do this before you sign a pilot agreement, because the answer should decide whether the pilot is worth having at all.