AI agents can now carry their own cryptographic, auditable identity inside Google Cloud's infrastructure — not a generic service account shared across dozens of automations. On August 22, Google Cloud made the Agent Identity auth manager and Agent Identity APIs generally available (GA) inside IAM, its cloud access-control service. The move landed the same week a survey of 235 large-enterprise security leaders found that 92% of them don't actually know how many AI agents are running inside their own organization.
What Changed
Agent Identity gives each agent an identity based on the open SPIFFE standard — an X.509 certificate and a unique identifier tied to that specific agent's lifecycle, rather than a generic service account reused across multiple automations, which is the norm today. With this identity, an agent authenticates on its own to MCP servers, cloud resources, and other agents — acting on its own behalf or, via OAuth delegation, on behalf of an end user. The Agent Identity auth manager works as a centralized credential vault and authentication broker, already integrated with IAM policies, Principal Access Boundary, and VPC Service Controls (that specific integration reached GA on August 14). In practice: audit logs now show exactly which agent did what, when, and under which permission — not "service account X made a call," but "agent Y, scoped to Z, accessed resource W."
Why It Matters
The timing isn't a coincidence. Gravitee's "State of AI Agent Security 2026" report — 235 large-enterprise security leaders, part of a broader survey of 900+ executives, cited by VentureBeat — shows the scale of the problem this infrastructure is meant to address: 88% of organizations reported confirmed or suspected AI agent security incidents in the past year; 71% say their agents access core systems like ERP, CRM, and financial platforms, but only 16% can govern that access effectively; and 86% enforce no access policy specific to AI identities. Adoption outran the ability to audit it. Tools like Agent Identity don't solve governance by themselves — but they remove a real technical excuse: an agent can now be tracked with the same rigor as an employee or a service.
The Impact for Brazil
Brazilian companies have been adopting AI agents at a fast clip — in some sectors, outpacing global averages, as we've covered here before. The problem is that the same speed that drives results also drives exposure: an agent running on a shared credential, with no defined scope and no clear audit trail, is a security and compliance risk (LGPD included) just as real as any misconfigured legacy system — except driven by an autonomous decision, not a human bug. IT and security teams already running workloads on Google Cloud can now retire the generic-service-account-per-agent habit and move to individual, auditable identities — without waiting for an incident to justify the investment.
Entercast's Take
This is the third chapter of a storyline we've been tracking here: Sinch showed that Brazil leads the world in agent adoption but also leads in governance-driven rollbacks; Binance showed that serious builders put control in the architecture, not in after-the-fact auditing; and now the cloud infrastructure layer itself is turning that into a product — identity, scope, and audit trail per agent, not per system. For whoever leads AI adoption at your company, the practical lesson hasn't changed, only the tooling to act on it has: before scaling the number of agents in production, make sure each one has its own identity, minimum necessary permission, and an auditable log — because, per Gravitee, 92% of companies today can't accurately answer the most basic question of all: how many AI agents do you actually have running right now?