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.

API Keys Are Open Secrets

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.

Quick recap of part 1

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:

• Direct Invocation: Using the Model Armor SDK or API for granular control over pre-call and post-call sanitization.
• Built-in Integration: Configuring services like Vertex AI, GKE, and Gemini Enterprise to automatically enforce security policies through “Floor Settings” and user-defined templates without explicit API calls in your application logic.

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.

If you’re building agents with the Agent Developer Kit (ADK), you’ve probably realized that the standard request-response loop isn’t enough. Real-world agents need to enforce safety policies, log detailed metrics, and maintain state across turns.

To solve these challenges, ADK provides Callbacks. These are your hooks into the agent’s brain, allowing you to observe, intercept, and even rewrite execution flows on the fly. But with great power comes great responsibility—and a few ways to shoot yourself in the foot.

The Model Context Protocol (MCP) is unlocking a new era of connectivity between LLMs and our data. But as we move from “cool demos” to production systems, we are hitting a wall that every API developer recognizes, yet few are prepared for: Versioning.

If you treat an MCP server exactly like a standard REST API, you will break your agents.

While a standard API usually breaks loudly (throwing 400/500 errors) when a contract changes, MCP tools often break silently. A changed tool description or a renamed parameter doesn’t just cause a validation error; it causes the LLM to hallucinate, misunderstand its instructions, or fail to execute a Critical User Journey (CUJ) that worked five minutes ago.

The Gemini CLI offers flexible authentication strategies to secure your Model Context Protocol (MCP) connections. Whether you are connecting to a simple MCP server exposing a couple of tools or a strictly governed enterprise service on Google Cloud, selecting the right authentication method is critical for both security and usability.

Defining “Security” in a CLI Context

Before diving into configuration, it is important to define what “secure” means when running a local CLI. We aren’t just talking about encryption in transit (HTTPS); we are talking about Local Credential Management and Token Lifespan.