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.

When we think of AI agents, we almost instinctively picture a chatbot: a user types a question, and the agent replies immediately. This request/response model is great for direct human interaction, but it doesn’t fit every use case.
Real-world enterprise systems are often distinct, disparate, and disconnected. They communicate through events—messages sent between systems to trigger actions asynchronously. If you want your AI agent to automate complex orchestrations (like processing insurance claims, analyzing logs as they arrive, or summarizing documents uploaded to a bucket), you need to break out of the synchronous “chat” loop.
In this post, we’ll explore how to plug an AI agent into an event-driven architecture. We will move beyond the standard API call and look at how to trigger a Python-based agent asynchronously using Google Cloud Pub/Sub and Eventarc. This approach allows you to integrate AI into established interfaces without modifying them, effectively turning your agent into a silent, scalable background worker.

Agent Development Kit or ADK from Google is one of popular frameworks for developing AI applications. It provides a rich set of instruments for developers saving the development time and enabling the use of the industry’s best practices. One of such instruments is session management. It is used to maintain a state of the user’s session during interaction with agents. ADK provides several implementations of the session management tool to be used for development, for use with relative databases and for maintaining state using Vertex AI - a Google Cloud platform for AI applications and ML models. You can find a lot of information about session management with ADK. You can read documentation or to learn about managing state and memory. And there is more.

Enabling authentication for your Cloud Run application is easy ‒ a single mouse click (or parameter in your CI/CD) without writing any code. Calling this application from another is less straightforward. It may be easy when both a caller and called applications are hosted under the same identity in Google Cloud. In the rest of cases, it requires acquiring an identity token.

A problem begins with documentation. Sometimes it isn’t clear whether the described token is an identity token or access token. While the first is good for invoking endpoints of user’s applications on Google Cloud, the second is good only for calling Google APIs.

Hey there, fellow AI application builders. Ever feel like your AI assistants are a bit like magic? You whisper a command, and poof – things happen. From booking flights to drafting emails, these intelligent agents are becoming an indispensable part of our lives. And behind a lot of this magic, especially when it comes to connecting AI models to the real world, is something called the Model Context Protocol, or MCP.

Have you ever found yourself grappling with observability instrumentation, even with tools like OpenTelemetry? This challenge becomes even more pronounced when developing Agentic applications, where understanding internal workflows is paramount. There are many frameworks that help developers to create an Agentic application. I’d like to review what observability data is generated when developers use the Agent Development Kit (ADK) from Google. ADK framework comes with logging and tracing instrumentation out-of-the-box.