Securing AI Agents on Google Cloud: An SRE and Platform Engineer’s View

Google Cloud recently published a 28-page ebook called Secure AI innovation: Securing the agentic enterprise on Google Cloud. Six chapters, a lot of product names, and one big message: AI agents are now part of your production estate, so secure them like it.

TL;DR

• The core idea is right. Treat AI agents as a new kind of workload with their own identity, their own guardrails, and their own monitoring.
• The 4-stage model (Architect, Inventory, Intercept, Defend) is a useful mental map. I would add a fifth stage: Operate and Retire.
• Many numbers come from Google, Google Cloud Next talks, and Wiz (which is now part of Google). Good signals, but read them as directional.
• The hardest part isn't buying the tools. It's making the secure path the fastest path for developers. That is a platform engineering problem, not a security product problem.

The ebook at a glance

Now let's go chapter by chapter.

Chapter 1: Securing the baseline

What the ebook says, in short: Shared service accounts and long-lived keys were never built for autonomous agents. Each agent should get a dedicated identity that lives only as long as its task, get extra privilege only when needed (Privileged Access Manager), and be fenced in by a Principal Access Boundary. Under that sits the Enterprise Foundations Blueprint: infrastructure as code, Cloud Build pipelines, SLSA Level 3 provenance, Binary Authorization, Shared VPC, and VPC Service Controls.

One stat that stuck with me: non-human identities already outnumber humans by a huge margin in cloud environments (the ebook says 82x). Agents will push that number higher, fast.

🛠️ SRE view

A unique identity per agent is not only a security win. It's an observability win. During an incident, the first question is always "who did this?" With shared service accounts, the honest answer is often "something, somewhere." With per-agent identity, you can actually answer it.

But there is a catch with identities tied to the task lifecycle. If the identity disappears when the task ends, make sure the evidence does not. Export audit logs to a log sink with retention that matches your compliance needs. Your postmortem might happen three weeks after the agent is gone.

🏗️ Platform engineering view

Nobody should hand-craft agent identities. Bake it into the golden path. When a team scaffolds a new agent from your template, it should come with its own identity, a narrow role set, a boundary policy, and labels for owner, environment, and cost center. Those labels pay off twice: once for security, once for FinOps when someone asks why the AI bill doubled.

On VPC Service Controls: it is powerful, and it is also famous for breaking things on day one. Roll it out in dry-run mode first, watch what would have been blocked, then enforce.

💻 Builder view

The hardest question is not "how do I give an agent an identity?" It's "what permissions does this agent actually need?" Agents are not deterministic. The tools they call can change from one prompt to the next. My approach: start narrow in dev, watch the denied calls, widen permissions on purpose, and treat every permission change like a code change that goes through a PR.

I also liked the warranty claim example, where a customer-facing agent talks to backend data agents using real identities instead of shared keys. It's boring and practical, which is exactly what this space needs more of.

Chapter 2: Governing the AI supply chain

What the ebook says, in short: Under deadline pressure, developers plug in third-party agent skills without review. The ebook claims more than 15% of skills in public marketplaces are malicious, and 68% of organizations run self-hosted models buried inside third-party software without knowing it. The answer is a central hub: Agent Registry, Wiz AI-BOM for discovery, ADK session isolation, Agent Gateway, managed MCP servers, an auth manager that keeps tokens away from the agent, and a security dashboard. Best Buy shares how they isolate high-risk agents on Cloud Run with their own containers and add a human approval step before risky API calls.

A quick naming note for readers: the ebook says "Gemini acts as the control plane." Many people will picture the chat app. From what I have seen, read it as the Gemini Enterprise agent platform side of Google Cloud, where things like the registry live.

🛠️ SRE view

Every third-party skill or MCP server is a dependency that can change behavior without you ever deploying anything. That's a reliability risk as much as a security risk. Pin versions. Route skill upgrades through the same change process as any other production change. An unpinned skill is config drift you can't see.

🏗️ Platform engineering view

Shadow AI is a symptom, not the disease. Developers go around IT when the official path is slower than their deadline. We saw this with containers, with npm packages, with Terraform modules. AI skills are just the next round.

The fix is an internal catalog that is easier to use than the public marketplace: pre-approved skills, one-command onboarding, and a fast review SLA for new requests. If approval takes three weeks, people will find another way. Every time.

💻 Builder view

The most underrated line in the whole ebook is from Best Buy: keep deploy-time permissions separate from runtime permissions. The pipeline that deploys your agent should never share an identity with the running agent. We learned this lesson years ago with CI service accounts. Let's not learn it again.

On human-in-the-loop approvals: I'm a fan, with one warning. If a person approves 200 requests a day, they stop reading them. Gate on risk, not on everything. Track how long approvals take and how often people reject. A rejection rate of zero usually means the gate is theater, or it's in the wrong place.

Chapter 3: Enforcing the guardrails

What the ebook says, in short: Runtime protection has two layers. First, access control at the Agent Gateway, so agents only reach systems they are approved for. Second, intent control, where filters look at what a prompt is really trying to do. Model Armor screens prompts for injection and jailbreak attempts and redacts sensitive data. Agents also validate inputs with strict rules, like checking that a serial number is only letters and numbers before it ever touches BigQuery.

One quote from Abhishek A. Hemrajani of Google Cloud Security sums it up well: "Agents are the new insider threats." I agree. An agent doesn't need bad intent to drop a table. It just needs to be confused.

🛠️ SRE view

Every inline check is another hop in the request path. The ebook says Model Armor adds no latency. Maybe it's small, but I would never take that on faith. Measure p95 and p99 in your own setup and include it in your latency SLO.

More important: decide your failure mode before the incident. If the gateway or the screening service is slow or down, do agents fail open or fail closed? That's a business decision, not a technical one. Write it down and get someone to sign off on it.

🏗️ Platform engineering view

Put guardrails in shared infrastructure, not in each agent's code. Ten teams writing ten prompt filters means ten different bugs. Central policy at the gateway, with team-level config for what's allowed.

And from a FinOps angle: screening every prompt and response is not free. Budget for it per agent, and watch it, especially for chatty agents.

💻 Builder view

The serial number example is my favorite part of this chapter because it's old-school engineering. Input validation. Parameterized queries. LLM guardrails don't replace basic hygiene. Never let a model build a raw SQL string from user text. A smart filter in front is great, but a strict schema behind it is what saves you.

Chapter 4: Fighting AI threats with AI defense

What the ebook says, in short: Attackers move at machine speed. The ebook cites an estimated mean time to exploit of negative seven days, meaning exploits often show up before the patch does. The answer is a find-and-fix loop: Wiz maps risks across your stack, CodeMender proves a vulnerability is real by trying to exploit it in a sandbox, and then generates a tested fix that shows up as a pull request for a human to approve. Wiz Red Agent tests from the outside, Wiz Blue Agent adds runtime context during incidents, and behavior analytics watch for agents acting out of pattern. The ebook also shares a story of one agent making 42,000 cloud API calls and 300 sensitive IAM changes in a single hour.

An honest note while reading: Wiz is now part of Google, so when the ebook calls Wiz the recommended standard for multi-cloud, that is Google recommending Google. It doesn't make it wrong. Just read it with that in mind.

🛠️ SRE view

42,000 calls in an hour is about 12 calls per second, nonstop. Detecting that at machine speed is good. But my first question is: why did nothing stop it?

Classic SRE tools apply directly to agents:

• Quotas and rate limits per agent identity
• Circuit breakers when error rates or call volumes spike
• A real kill switch that someone on call can use in seconds
• An alert on any IAM change made by an agent. That should be a rare event, not a dashboard metric.

Prevention through limits is cheaper than detection after the fact.

🏗️ Platform engineering view

Automatic patch PRs sound amazing until 40 of them land on a Monday. Fix generation is cheap. Human review is the bottleneck. Route them with CODEOWNERS, batch related fixes, and track merge rate, revert rate, and time to merge. If the revert rate starts climbing, slow the machine down.

💻 Builder view

Exploit verification in a sandbox is the feature I'm most excited about in this whole ebook. False positives destroy trust in security scanners. Teams learn to ignore them. Proving a vulnerability is actually exploitable changes the conversation from "your scanner is noisy" to "here's the proof, here's the fix."

Chapter 5: Achieving digital sovereignty

What the ebook says, in short: Regulated industries need control over where data lives and who can touch it. Customers own their keys through Cloud KMS, Key Access Justifications add an approval step before Google can decrypt, and Secret Manager keeps credentials out of agent code. There are three sovereign options: a data boundary in the public cloud through Assured Workloads, dedicated regional clouds run by local operators, and fully air-gapped Google Distributed Cloud. Google also points to its Leader position in the Forrester Wave for sovereign cloud platforms.

🛠️ SRE view

Each sovereign option changes your operating model, not just your compliance checklist. Air-gapped means no pulling the latest model on a whim, no SaaS observability tools, and patching on your schedule with your own people. Plan for update lag and for on-call depth.

Also: owning your keys means you can lose your keys. Locking yourself out of your own data is an outage you caused. Test key rotation and break-glass access the same way you test disaster recovery.

🏗️ Platform engineering view

The biggest promise here is a consistent experience across all three options. That's the part I'd verify hardest. Do the same Terraform modules work? The same pipelines? The same agent templates? Wherever they differ, document it clearly in your platform docs so teams don't find out in production.

💻 Builder view

I still see API keys sitting in agent code, and sometimes inside system prompts. Remember that agents read their own context, and that context often ends up in logs. A secret in a prompt is a secret in your logs. Pull secrets at runtime, never hardcode them, never put them in prompts.

One caveat: strong statements like "Google cannot decrypt without approval" depend on how your keys are set up. Check exactly which configuration gives you that guarantee before you repeat it to your auditors.

Chapter 6: Bridging AI velocity and governance

What the ebook says, in short: It wraps everything into a 4-stage lifecycle. Architect (identity and perimeters), Inventory (discovery, registry, provenance, human approvals), Intercept (gateway control and prompt screening), and Defend (threat detection, behavior monitoring, and automatic fixes). Sovereignty and key control run alongside all four.

My take: This is a good map, and I'll probably use it in conversations with leadership. But from an SRE and platform view, two stages are missing.

1. Operate and Retire. Who is on call for an agent? Where is the runbook for "agent is doing something weird"? How do you shut down one agent without taking down the others? And when an agent is no longer needed, who revokes its identity, removes its skills, and deletes its connections? Agents rarely die cleanly. A forgotten agent that still has permissions is tomorrow's breach.

2. Evaluate. Test agent behavior before production, not just the code. Run red-team prompts in CI. Run regression evals whenever the model version changes. A model upgrade is a deployment. Treat it like one.

And one more thing none of the four stages mention: cost. Every layer here (screening, telemetry, behavior analytics, sandboxed scans) adds spend. Security that nobody can afford gets turned off quietly.

Where I'd push back overall

• The numbers. Many stats come from vendor reports and conference talks. They are useful signals, but go to the primary sources before you put them in a board deck.
• The product density. Smaller teams can feel lost here. You don't need every product on day one. Unique identities, no static keys, input validation, rate limits, and good logs will get you far.
• New and preview features. Some of these capabilities are very new. Check what's generally available before you build a production roadmap on it.
• Absolute language. Words like "total governance" and "never" make me nervous. Security is never total. It's layers, tradeoffs, and good habits.

My Monday morning checklist

If I were starting from this ebook tomorrow, here's my order:

1. List every agent running today, including the "just an experiment" ones.
2. Find any agent using a shared service account or a static key. Fix those first.
3. Add per-agent quotas and a kill switch someone on call can actually use.
4. Put a central gateway and prompt screening in front of agents, and measure the latency it adds.
5. Pin third-party skills and MCP servers, and route upgrades through change management.
6. Decide fail-open vs fail-closed for each guardrail, and write it down.
7. Label every agent resource with owner, environment, and cost center.
8. Write one runbook for "an agent is misbehaving" and run a drill.

Final thought

The ebook says security is the enabler, not the blocker. I agree, with one condition: it's only true if the platform team makes the secure path the easy path. Tools give you the controls. Golden paths, templates, and fast reviews are what get developers to actually use them.

Over to you: what is the hardest part of securing agents in your org right now? Identity, shadow AI, guardrails, or just knowing which agents exist? Drop it in the comments. I read every one.

Sources

• Ebook landing page: https://cloud.google.com/security/resources/secure-ai-innovation
• Ebook PDF: https://services.google.com/fh/files/misc/secure_ai_innovation_securing_the_agentic_enterprise_on_google_cloud.pdf

All opinions are my own, based on my experience in SRE, platform engineering, and building with AI agents.