This is a submission for the Google Cloud NEXT Writing Challenge

About halfway through the Developer Keynote, Emma Twersky tried to get the Planner Agent to increase the race budget so every runner could get glow sticks and LED sunglasses.

And to everyone’s surprise, it worked.

The next speaker was invited on stage to explain how to prevent exactly that from happening.

I couldn’t move on from that because what just happened was one of the most honest and quietly alarming demonstrations I've seen at a tech conference in years. An agent with write access to a financial database was talked into making an unauthorized budget change through normal conversation.

Not through a hack or an injection attack. Just a user asking nicely.
And most of the discussion I've seen coming out of NEXT '26 is about Gemini 3.1 Pro, the new TPUs, and whether "vibe clouding" is going to stick as a term. We should be talking about something more consequential: what happens when your agents can discover each other, delegate to each other, and act on your behalf and who controls that?

What she demonstrated, before Ankur Kotwal came on stage to fix it, was a real attack surface. The Planner Agent had access to a Finance MCP server with both read and write tools. Emma asked it, through normal conversation, to increase the budget. The agent complied because nothing told it not to. There was no policy. There was no boundary. There was just a capable agent, a persuasive user, and a write-enabled tool sitting there waiting.

Ankur's fix was genuinely clean. He navigated to Agent Gateway, selected the Planner agent, located the Finance MCP server in its allowed tools, added a condition named read-only-finance, set ReadOnly to True, and saved. The same prompt now fails gracefully.
The mechanism underneath Agent Identity is more interesting than the UI makes it look. Unlike service accounts, which function like a master keycard shared across an entire system, each deployed agent gets a unique cryptographic identity. Policies attach to that identity. The gateway enforces them on every call. It's zero-trust, properly applied to a new kind of principal: not a user, not a service, but an agent.

This is the architecture the industry needs. The uncomfortable part is that we needed it because agents behave like eager-to-please interns who will do whatever they're asked unless someone explicitly wrote down that they shouldn't. They don't have judgment. They don't have intent. They have instructions and tools, and if the instructions don't say "don't touch the budget," the tools will touch the budget. Organizations are deploying agents into production faster than they're defining what those agents are and aren't allowed to do and most of the time, nobody finds out until something goes wrong. An overprivileged agent doesn't need to be hacked. It just needs to be prompted.

Richard Seroter framed this as a reason to "shift down, not left" on security. The industry has spent a decade telling developers to own security earlier in the pipeline — shift left, catch it in the IDE, integrate it into CI/CD. Seroter's argument was that this model breaks under agentic workloads. You can't ask every developer building agents to be a security expert. The platform needs to absorb that responsibility. Agent Gateway, Agent Identity, and Model Armor are Google's answer to where that responsibility lives.

It's a compelling argument. It's also, notably, an argument for why you should run your agents on Google Cloud.

What I really loved is that they showed the exploit first. Then they showed the fix. They didn't start with the policy screen and say "imagine if this didn't exist." They let Emma actually do the bad thing, let the audience have a moment of "wait, that worked?", and then brought in the answer.

Most conference security demos work the other way, they show you the protection and imply the threat. Google showed you the threat and then showed you the protection, which means you actually understand what you're protecting against.