I Defend Networks for a Living. Google I/O 2026 Just Changed My Threat Model

Everyone reading about Antigravity 2.0 this week is a developer celebrating what they can now build....

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.md system 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.