Every agent that uses an MCP server needs the server’s URL. That seems harmless until the server moves to another region, gets redeployed under a new name or gets a separate staging copy. Then you have to update and redeploy every agent that has the URL hardcoded, and often nobody finds out until something breaks. With a few agents and a dozen servers, that one pasted URL becomes a real maintenance burden.
Cloud Run is my primary deployment platform when I experiment with AI Workloads or build samples for conferences and codelabs. When I got early access to its new feature called Cloud Run instances, I was a bit confused. I mean, Cloud Run already offered three execution models: Services for transactions and request-response apps, Jobs for batch processing, and Worker Pools for background tasks. Why introduce a fourth option?
Initially I thought that my “aha” moment would come when I tried to build an AI agent that runs long-lived sessions and needs to persist the session’s temporary data locally. Then I tried to find a difference between using an Instance and deploying the agent as a Cloud Run Service. I mounted a storage volume to my service and instrumented the agent with a tool to read and write state data to that volume. I also added an ephemeral disk to store temporary data that the agent generated mid-execution. The agent managed long-lived sessions without a problem. It scaled to zero minimizing costs when left alone and resumed to the same session operation when called later. The known problems of mounting Cloud Storage buckets via FUSE such as high latency and lack of true POSIX locking were there. And my ephemeral disk reset each time the service scaled to zero. “Well,” I thought, “it would be nice to have storage that behaves like a persistent local disk.” However the same would be true for Cloud Run Instances too. This experience supported my initial confusion about Instances.
When AI skills started popping up everywhere, my first impulse was to collect them like browser extensions. But treating skills like plug-and-play software misses a fundamental truth: a skill isn’t just a package; it’s a piece of someone’s thinking. In the real world, relying on someone else’s knowledge is never the same as using your own head. You can read someone’s notes or memorize their checklist, but until you understand the principles yourself, you can’t adapt when things go sideways. AI skills operate on that exact same principle.
When building Generative AI applications for the enterprise, you are likely hyper-aware of the risks surrounding sensitive data. The knee-jerk reaction for many engineering teams is to aggressively block all sensitive data ‒ ranging from PII to financial records and internal credentials ‒ from absolutely everywhere in the stack.
But a blind, one-size-fits-all approach introduces its own massive headaches. It compromises internal reasoning, ruins user experiences and breaks downstream autonomous systems. As I promised in the first “How to wear Model Armor” post, we are going to dive into exactly when to keep sensitive data out of your language models, the reasons you must often avoid de-identifying an agent’s output, and how to orchestrate this balance using Google Cloud’s Sensitive Data Protection (SDP) and Model Armor.
This post was originally published on Google Cloud Blog for Developers and is posted here for “bookkeeping”.
In Google Cloud, Identity and Access Management (IAM for short) helps you maintain access control over your cloud resources and operations. While it includes other features, this is its primary purpose. If you ever tried to harden security over your application, you know the importance of the Principle of least privilege (PoLP) ‒ grant the absolute minimum permissions to your users and workloads to allow them to perform their tasks. You reach it through use of predefined roles and custom roles and setting up a combination of Allow and Deny IAM policies at project, folder, or organization level. Using a combination of Allow and Deny policies along the resource hierarchy is an effective way to control access. This approach lets you enforce PoLP across many different scenarios.
The Agent Development Kit (ADK) simplifies authentication for agents and tools, but is more challenging with the LiteLLM connector when accessing models hosted on Cloud Run. This guide explores how to acquire Google-signed OpenID (ID) tokens and inject them into the LiteLLM communication channel using ADK.
Google Cloud Run provides a robust, built-in access control mechanism based on enforced authentication and IAM policies. When it is enabled, only calls that are made by authenticated accounts which have the specific Cloud Run Invoker role, are accepted, protecting your service from unauthorized invocations.
This post was originally published on Google Cloud Blog for Developers and is posted here for “bookkeeping”.
Disclaimer: This post is not about costs or disputing billing charges caused by API keys use.
Today, AI services rely heavily on API keys. To run AI agents, users provide API keys that signify paid tokens, subscriptions, or paid accounts. While API keys are easy to use, it is just as easy to use them unsafely. The result of a hijacked key is a compromised environment that is misused or abused by perpetrators.
The first post about Model Armor, explored the fundamentals of Google Cloud’s managed security service for Generative AI applications, which provides a model-agnostic defense layer to sanitize both prompts and model responses.
It covered the two primary patterns for integrating Model Armor into your stack:
And it walked through the practical configuration of these integrations using gcloud CLI and Terraform, establishing a secure baseline for your GenAI pipelines. In this post I shift my focus to examine how direct invocation works in practice. I will review the methods of interpreting sanitize API responses and incorporating the API calls in two agent frameworks: LangChain ‒ probably the most widespread framework today for implementing agentic workflows and the Agent Development Kit (ADK) which I personally prefer for its simplicity.
I’ve built a showcase demo for Google’s Cloud Next 2026 and had a chance to explore in-depth the Binary Authorization service of Google Cloud. Surprisingly, I discovered that many things about this service aren’t exactly as straightforward as I perceived them to be. And it seemed to me as a good opportunity for “X things about a Y product…” post.
If you’re new to the service, Binary Authorization helps you enforce security on container-based applications. To simplify it further, the service manages attestations of the container images and helps define which attestations are required to deploy a container image to GKE or Cloud Run. Here are 6 things that I learned while setting up Binary Authorization to work for my demo.
Model Armor in Google Cloud is a managed security service that provides a programmable defense layer to sanitize prompts and responses for Generative AI applications. At its core, Model Armor is a model-agnostic, API-first security solution designed to intercept and sanitize the I/O of Large Language Models (LLMs). It allows developers to define and enforce safety policies — referred to as Templates — that sit between the user and the model, ensuring that interactions remain within organizational and security guardrails. Unlike Google Cloud Armor that focuses on Layer 7 web traffic and DDoS protection, Model Armor operates on the semantic and content layer of GenAI. You can watch a youtube video to see a practical demonstration of these capabilities in action, including live examples of how the service intercepts and handles malicious requests.
