Google Agent Identity, Access Management, and Observability

Enterprise agents do not behave like traditional users, services, or static workloads. They can receive goals, call tools, use memory, operate across systems, and act with different levels of autonomy—changing how teams need to think about identity, access, containment, and observability.

This work focused on agents operating in high-risk internal environments, including agents with access to Google3, Google’s primary internal monolithic source-code repository. Google3 supported engineering workflows for business-critical ecosystems including Search, Ads, YouTube, Workspace, and Gemini-related AI systems—so access, containment, traceability, and assurance mattered immediately.

Antigravity, created by Google DeepMind, was the primary early agent focus. But the platform needed to scale beyond one IDE agent, one capsule workflow, or one framework. The promise was speed. The risk was losing track of who or what was acting inside sensitive systems.

This was the enterprise agent problem: many agents, many Product Areas, many frameworks, and no shared control model. The experience needed to answer practical questions fast: who controls this agent, what can it access, what did it do, where did it operate, and what happens when something looks wrong?

I helped turn an ambiguous agent-security problem into clearer product direction, MVP scope, prototypes, and shared language—while supporting two urgent Google DeepMind pilots that made the platform concepts tangible.

My work centered on four priorities:

• Shaping early product strategy and roadmap direction for Enterprise Agent IAM and Observability
• Translating product, security, and engineering ambiguity into UX priorities, MVP scope, and pilot-ready flows
• Building research-informed Agent IAM prototypes informed by PM documentation, IAM concepts, stakeholder input, desk research, and UX research
• Using prototypes, research synthesis, and visual storytelling to support Director and executive reviews, gather feedback, and build program traction

Agent identity became the central design lever. Without a clear identity model, teams could not reliably answer who controlled an agent, what it could access, where it ran, what it did, or who was accountable.

That sounds like plumbing, but it was the product experience. If those concepts were unclear, setup became fragile, troubleshooting became painful, and security teams lost the context they needed.

A core design shift was tying permissions to agent identities rather than individual deployments. The model helped clarify whether an agent was personal or shared, which permissions belonged to it, where it ran, and how reviewers or operators could reason about access over time.

Antigravity made the enterprise-agent problem concrete in two ways.

First, the Google DeepMind pilots focused on the Antigravity system and deployment setup: how IDE agents could operate in secure capsule environments with the right identity, access provisioning, containment, and recovery paths.

Across two DeepMind pilots, setup moved from manual Security and SRE support toward a more automated model for identity, access provisioning, and capsule deployment. The work exposed capacity limits, setup friction, reliability issues, and unclear recovery paths.

Second, I used the Antigravity IDE platform itself—including Skills and MCP setup in my own environment—to build Agent IAM prototypes that explored how teams could reason across agent identities, access boundaries, activity signals, metrics, and containment needs.

That proximity mattered. Building inside Antigravity helped the prototype stay close to the same setup, access, reliability, and failure-state issues the pilot teams were working through.

The pilots also showed why failure clarity mattered. Vague or silent failures were not just support problems. In enterprise systems with potential access to Google3, poorly monitored or poorly contained agent activity could create business-critical risk around unauthorized access, system integrity, data exposure, and assurance. That made containment and observability core platform requirements, not dashboard enhancements.

Observability was not just about knowing whether agents were running. Teams needed an identity-based view of agent actions so they could distinguish agent-driven work from human activity and investigate risky behavior.

These agents were not isolated experiments. Major Product Areas across Google—including Search, Ads, YouTube, Workspace, and AI model teams—were building or evaluating agents for specialized internal tooling and customer-facing workflows.

Because agents could emerge across different Product Areas, frameworks, and execution environments, monitoring could not depend on one implementation pattern. The platform needed a common way to reason about identity, access, attributes, activity, trust, and response.

I explored this through an Agent IAM prototype built around three connected capabilities:

• A mock agent database modeled on real-world agent types, access patterns, and security concerns surfaced through desk research, internal documentation synthesis, and UX research
• Dynamic filtering patterns that let investigators narrow agent activity by high-security data domains, infrastructure jobs, access rules, unique identifiers, and system-specific attributes
• A Gemini-powered conversational layer that could reason across the agent registry and help investigators answer questions about identities, access enablement, metrics, ownership, and risk signals without sorting through massive lists manually

That pointed toward agent workforce management: a centralized way to understand which agents existed, who controlled them, what they could access, what they were doing, what risks they introduced, and what action teams could take when something looked wrong.

The goal was not more logs. It was helping teams move from raw attributes to situational understanding and actionable control.

Video by ai.google/safety

This work reinforced that enterprise agents need more than permission prompts, access policies, and dashboards. They need a control plane that makes identity, access, behavior, investigation, containment, and accountability understandable across the full lifecycle.

The most reusable shift was treating agent identity as the foundation for accountability. Given more time, I would deepen the relationship between identity, activity quality, trust signals, and mitigation workflows—so teams could detect risky behavior earlier and respond with more confidence.