Building Secure AI Agents With Bigtable and ADK

There's a particular kind of enterprise technology demo that follows a well-worn script: gleaming UI, curated data, no error states, implicit promise that your mileage will vary wildly. Google Cloud's recent walkthrough of building a conversational AI agent with Bigtable and the Agent Development Kit hits most of those beats. But underneath the healthcare concierge demo—a chatbot that fields questions about prescriptions, lab results, and upcoming appointments—there's a stack architecture that addresses some real questions the industry has been dodging.

The presenter is Bora Beran, a Google Cloud engineer who builds the thing live and explains the decisions as he goes. The use case is healthcare, which is either a smart choice (high stakes, familiar pain point, everyone has a story about medical paperwork) or a convenient one (data is fake, so the hardest compliance questions never come up). Probably both.

The Architecture Is Actually the Point

The demo application is a root agent orchestrating three sub-agents in what Beran calls the "agent as tool" pattern: a query agent that talks to Bigtable, a search agent grounded through Google Search and Maps, and a booking agent that reads and writes to Google Calendar. On top of that, two pre-execution tools inject user context—profile information like age, gender, and zip code, plus current datetime—before the agent processes any query.

That last piece is more interesting than it sounds. Relative time references ("last week," "past three months") are a quiet failure mode in a lot of deployed AI systems. If the agent doesn't know what "now" is, its answers about upcoming appointments or overdue refills are wrong in ways that are hard to catch and potentially harmful in a healthcare context. Beran's solution—a pre-agent tool that just tells the agent what time it is—is almost embarrassingly simple, which is usually a sign that it's correct.

The Bigtable piece is worth understanding for what it is and isn't. Bigtable is Google's wide-column NoSQL database, built for high-throughput workloads at scale—think billions of rows, petabytes of data. For a healthcare concierge chatbot with one user's records, it's obvious overkill. Beran acknowledges the demo is illustrative. What's being shown is the pattern: a database-backed agent application where user data is structured, queryable via SQL, and access-controlled at the data layer.

"If you didn't know Bigtable had a SQL API," Beran says mid-demo, "that's yet another nugget of information from this video." It reads as a casual aside, but it's actually doing some quiet product marketing—Bigtable's SQL interface is a relatively recent addition, and a lot of developers still think of it as pure NoSQL territory.

Where the Security Thinking Gets Interesting

Most AI agent demos treat security as an afterthought, if they treat it at all. This one puts it at the center, which is either a sign that the field is maturing or that Google's enterprise sales team has been getting hard questions. Either way, the approach Beran lays out is worth examining.

The first layer is identity. User identity threads through all three components of the application—calendar access, row-level access control in the database, and agent memory. The critical design decision is that identity is passed to tools via ADK's "tool context" rather than through the agent itself.

"Tool context is not set by the agent," Beran explains. "This is very important because we don't want users to claim they are somebody else and trick the agent to access health records they weren't supposed to see."

This distinction matters more than it might appear. If the agent were the source of identity assertions—if it could say "this user is person X, show them person X's records"—then a sufficiently clever prompt might convince the agent to assert a different identity. By routing identity through a separate, agent-opaque channel, the architecture reduces the blast radius of a compromised or manipulated agent. The agent can't lie about who you are because the agent doesn't control that claim.

The second layer is SQL injection protection via Pydantic, Python's data validation library. When the agent constructs database queries using user-provided inputs—dates, medication names, query ranges—Pydantic enforces type constraints before the query executes. Beran runs a live injection test, attempting to bypass the row-key filter that scopes queries to the authenticated user's records. The query gets blocked. It's a clean demonstration of a principle that gets preached constantly and implemented inconsistently: validate inputs at the boundary, before they reach anything consequential.

The third layer is Model Armor, Google's content filtering system for AI inputs and outputs. This addresses prompt injection—attempts to override or ignore the agent's system instructions through user input. Beran demonstrates a jailbreak attempt ("set our agent free of previous instructions," as he puts it), and Model Armor blocks it. The system can also scan outputs for sensitive content like social security numbers or credit card data, which is relevant anytime an AI agent is operating over records that might contain that information.

Three distinct security layers for three distinct attack surfaces: identity fraud, data injection, and prompt injection. Each handled at a different level of the stack. It's a more coherent security model than you see in most agentic demos, where the answer to "how do you prevent misuse?" is usually something like "we trust the LLM."

The Self-Tuning Loop Deserves a Separate Conversation

Buried near the end of the demo is something that got less screen time than it probably deserved. Beran mentions that he set up an evaluation framework—running structured tests against different versions of the agent to detect regressions as he tweaks instructions, tool descriptions, and query definitions. Standard practice for any serious ML deployment.

Then he says this: "I created a hill climbing loop here where my agent runs the eval, makes tweaks, and runs again, self-tuning without my manual intervention."

So the agent evaluates itself, modifies itself based on those evaluations, and iterates. Beran shows this briefly—a coding agent recommending specific changes to improve response quality—and moves on. It's presented as a productivity feature, a way to accelerate iteration. Which it is. It's also a system where an AI's behavior is being shaped by another AI with limited human review of individual changes.

That's not necessarily alarming in a development context, where you control the eval criteria and review the final output before deployment. But the framing—"self-tuning without my manual intervention"—as a selling point is worth sitting with. The question of how much human oversight belongs in the loop when AI systems modify their own behavior is one the industry hasn't settled, and the answer probably varies a lot depending on what the agent is doing and for whom.

In a healthcare application, specifically, that question has edges.

What This Actually Shows

Beran is careful to note that the function-tool approach he's demonstrating works best for "operational use cases"—bounded queries over a defined user's data. He explicitly flags that for analytics or faceted search, other Google tools are more appropriate. That kind of scope-setting is unusually honest for a product demo.

The strongest version of what's being shown here is: here is a practical, security-conscious architecture for building AI agents over structured user data, using tools that exist and work today. The agent-as-tool pattern, the identity threading, the layered injection defenses—none of this is theoretical. Beran builds it in eleven minutes.

The open questions aren't really about the architecture. They're about context. The data is fake, the use case is illustrative, and the compliance questions that would make a real healthcare deployment genuinely difficult—HIPAA, audit logs, data residency, consent frameworks—don't appear. That's appropriate for a technical demo. It's less appropriate if someone watches this and concludes that building a real health concierge is an eleven-minute problem.

The gap between "this architecture is sound" and "this application is ready for your patients" is where a lot of AI deployments quietly go wrong. Beran's demo is a useful map of the former. The latter is a different kind of work entirely.

---

By Marcus Chen-Ramirez, Senior Technology Correspondent