Everyone reading about Antigravity 2.0 this week is a developer celebrating what
they can now build. I read the same announcements from a different chair: I'm an
MSS Engineer at a Security Operations Center in Latin America. My job is to detect,
contain, and respond to threats across the networks where these tools will eventually run.
And Google I/O 2026 gave me a lot to think about — not because the technology is
dangerous, but because it introduces agent execution patterns that most security
teams are completely unprepared for.
This is that conversation. The one the developer track didn't have.
What Actually Shipped (The Security-Relevant Parts)
Let me be specific about what changed, because the details matter.
Antigravity 2.0 introduced:
- Subagent orchestration — one agent spawning and directing others
- Background cron workflows — agents running on schedules without human initiation
- Native credential masking and Git policy enforcement in sandboxes
- An
AGENTS.md/SKILL.mdsystem for defining agent behavior in markdown files
Managed Agents in the Gemini API lets any developer with an API key provision
an isolated Linux sandbox where an agent reasons, runs tools, executes code, and
browses the web. One API call.
WebMCP lets websites expose structured JavaScript functions and HTML forms
directly to browser-based agents.
These three things together describe a world where autonomous code execution agents
are a commodity, run on schedules, spawn children, interact with websites directly,
and are configured through text files that can be stored in version control.
That's a meaningfully different threat surface than "a chatbot that writes code suggestions."
The New Questions a SOC Has to Answer
I work with CrowdStrike Falcon and SentinelOne daily. Right now, when I see
suspicious process execution, I have a mental model: a human did something,
or malware did something. The attribution chain — even when complicated —
ultimately traces back to one of those two categories.
Agents break that model.
When Antigravity spawns a subagent that writes and executes code in a sandbox,
what does that look like in an EDR telemetry feed? Is it parent process → child
process in a way I recognize? Or does it look like a new process tree with no
obvious human ancestor? If my detection rules fire on "unusual process spawned by
browser," will they fire on legitimate agent workflows too?
I don't know yet. And neither does most of the security industry, because this
is genuinely new behavior at scale.
Background cron workflows mean agents acting without user sessions.
Traditional behavioral analytics lean heavily on user context — this process ran
while this user was logged in, doing these other things. An agent running on a
schedule at 3am has no user session. It looks anomalous by design. Either we
tune detection to exclude it (creating a blind spot) or we drown in false positives.
AGENTS.md and SKILL.md files are configuration-as-code for agent behavior.
That's elegant for developers. For security teams, it means agent behavior can be
modified by anyone with write access to a repository — and that modification
might not go through any approval workflow, might not trigger any alert,
and might not be reviewed by anyone who understands the security implications.
Prompt injection already exists as an attack class. Now imagine prompt injection
via a committed markdown file in a repository that a developer trusted.
What Google Actually Got Right (Security Edition)
I want to be clear: I'm not writing a scare piece. Several of Google's design
choices at I/O 2026 show real security awareness.
Cross-platform terminal sandboxing in Antigravity is a meaningful control.
Agents running in isolated Linux VMs with fresh filesystems per execution have
a much smaller blast radius than agents running in shared environments.
If an agent gets manipulated into doing something malicious, containment
is real — not theoretical.
Credential masking as a native feature is the right call. One of the
most common failure modes in early agentic systems was agents logging or
outputting credentials that were in their context. Building masking into
the harness rather than leaving it to individual developers reduces
that class of incident significantly.
Hardened Git policies mean agents can't arbitrarily push to protected
branches. Again — this is the right constraint to build into the platform.
Google clearly thought about the obvious attack surface. The question is
whether they thought about the non-obvious ones.
The Gap Nobody's Talking About
The gap is observability and auditability for security teams.
Developers have great new tools to build and run agents. What do security
teams get to monitor them?
Right now the answer appears to be: the same SIEM and EDR tools we already have,
which were designed for human-generated activity and are going to produce significant
noise when confronted with agent-generated activity at scale.
I'd like to see — and I'd argue the industry needs before this becomes mainstream
in enterprises — a few things that weren't in the I/O announcements:
Structured agent audit logs that are parseable by security tooling. Not
application logs, but something analogous to CloudTrail for agent actions:
what did this agent call, what files did it touch, what external requests
did it make, what was the decision chain that led to each action?
Agent identity in security context. When an Antigravity agent makes a
network request, what identity does it carry? Is it the developer's API key?
A service account? How does an IR team, post-incident, determine which agent
made which request with what authorization?
AGENTS.md change detection and alerting. If this file is where agent
behavior lives, security teams need to know when it changes — not as a
Git notification to a developer, but as a security event with context.
Why This Matters for the Developer Community
If you're building with Antigravity, Managed Agents, or any of Google's
new agentic tooling — this is on you too, not just the security team.
The security of AI agent systems doesn't live only in the platform controls
Google builds. It lives in how developers design agent scopes (minimal permissions,
always), how they handle credentials in AGENTS.md files (they shouldn't be there),
how they think about what happens when an agent receives unexpected input from
an external source it was instructed to interact with.
WebMCP being a structured interface rather than screen scraping is
actually a security improvement — it reduces the attack surface of
"agent receives malicious content from a web page and executes it."
But it doesn't eliminate prompt injection. A WebMCP endpoint can still
return instructions crafted to manipulate the agent's next action.
The developer and security communities need to have this conversation
together, now, before agent-generated activity is normalized in enterprise
environments and the anomaly detection window closes.
Google I/O 2026 built a remarkable platform. The security industry's job
is to make sure we understand it before the adversaries do.
Bals (Byron Lainez) is an MSS Engineer at Security Operations Center
in Guatemala, working daily with CrowdStrike Falcon. He leads
the AWS User Group El Progreso.
