Google Can Now Prove Which Agent Acted. Proving It Was Allowed To Is a Separate Question.

Three dates, kept separate

Nothing in this record happened today. On 14 August 2026, according to Google Cloud's own IAM documentation, Agent Identity itself reached general availability, Agent Identity Auth Manager was available in preview, custom Organization Policy constraints for Auth Manager were already generally available, and VPC Service Controls integration for Agent Identity was already generally available. On 22 August 2026, Auth Manager itself reached general availability, alongside its two supporting APIs, agentidentity.googleapis.com and agentidentitycredentials.googleapis.com. On 23 August 2026, Google updated several of the Agent Identity and Auth Manager documentation pages this record cites. The current radar date, 24 August 2026, is this record's own verification date, not a Google publication date, and this record does not describe Auth Manager, Agent Identity or anything underneath either one as launching today.

Those four dates are four different kinds of fact, and collapsing them is the easiest way to get this record wrong. Agent Identity itself is older still: Google previewed it publicly at Google Cloud Next 26 in Las Vegas, held 22 to 24 April 2026, months before the 14 August general availability date this record treats as the anchor for what is confirmed stable today. This record's own network access to docs.cloud.google.com, the host serving Google's IAM release notes, was blocked on every attempt, which means the exact day by day release note wording behind each of the three 2026 dates above could not be read directly in this session. What is independently corroborated, across repeated, differently phrased search passes that returned consistent detail rather than a single snippet's paraphrase, is the general shape and sequence: an April preview, a 14 August general availability milestone for Agent Identity that left Auth Manager in preview, and an 22 August general availability milestone for Auth Manager and its APIs specifically. An editor with direct browser access to docs.cloud.google.com should confirm the exact release note wording before treating the day level dates as beyond dispute.

What Agent Identity actually is, read against Google's own wording

Google's own documentation, corroborated consistently across this session's search passes, describes Agent Identity as a new, first class principal type, distinct from a human identity or a generic service account, built on the open Secure Production Identity Framework For Everyone standard, SPIFFE, and states that these identities are cryptographically protected, strongly attested and automatically provisioned. Read precisely rather than as marketing language, strongly attested resolves to a specific, checkable mechanism this record verified separately: access tokens Agent Identity generates for Google Cloud are cryptographically bound to the agent's own unique X.509 certificate, so a token copied out of its issuing environment cannot simply be replayed somewhere else. That is an attestation claim about the token's binding to a certificate, not a claim that the agent's own reasoning, code or behavior has been independently verified.

The identity itself is documented as tied to the lifecycle of the resource hosting the agent, rather than issued once by a developer and left to outlive whatever it was created for. That is a materially different lifecycle model from a manually created service account, which persists until someone deliberately deletes it regardless of whether the workload it was meant for still exists. This record did not find, in anything reviewed, a lower level technical description of exactly how that lifecycle binding is implemented, beyond the SPIFFE and X.509 certificate mechanics already stated, and does not infer a more specific mechanism than Google's own material documents.

A follow up verification pass run on 26 August 2026 surfaced one specific, checkable figure this record's earlier passes had not pinned down: Google's own material states each X.509 certificate an Agent Identity holds is valid for 24 hours, and that Google Cloud automatically keeps it current rather than leaving it to expire unrenewed. That is consistent with the lifecycle binding already described above, tied to the hosting resource rather than to a one time developer provisioning step, and this record treats the 24 hour figure and the automatic renewal as a specific, checkable claim about certificate freshness, not as a broader claim about how quickly a revoked or compromised identity stops being trusted, which remains a separate, undocumented question addressed in the ledger below.

Compared against a service account, three specific claims

Google's own material makes a direct comparison to service accounts, and states it in terms specific enough to check rather than as a general security claim. Unlike a service account, an agent identity is not shared by multiple workloads by default, cannot be impersonated, and does not let a developer generate a long lived service account key. Each of those is a distinct, checkable property, and this record treats them as three separate claims rather than one bundled guarantee.

Not shared by multiple workloads by default is a default, not an absolute. Google's own Auth Manager material, read alongside its own gcloud command reference, documents a workloadIds field on an AuthProvider that accepts one or more agent identity principals, meaning an operator can configure a single AuthProvider, and the third party credential behind it, to serve more than one agent identity at once. That is a configuration choice available to an operator, not evidence that Google's stated default has been misdescribed. This record keeps the two facts distinct: agent identities are not shared by default, and third party credential access through Auth Manager can be shared across more than one agent identity when an operator configures it that way. The first claim is about the identity primitive itself. The second is about a credential a separate system manages behind it, and this record does not let the first claim stand in for the second.

Cannot be impersonated and does not allow long lived keys are both stated plainly and consistently across this record's search corroboration, without a documented exception this record could find. What Google's own material does not say, and what this record does not infer from it, is that an agent identity cannot be compromised. Impersonation and key generation are two specific attack paths a service account exposes that Google states Agent Identity closes. Neither closes every path a compromised host, a compromised credential retrieved through Auth Manager, or a manipulated agent could still exploit, and this record treats generalizing cannot be impersonated into cannot be compromised as exactly the kind of overclaim its own verification standard exists to catch.

Not one runtime: where Agent Identity is actually documented as running

Google's own material, read across the IAM documentation and the Gemini Enterprise Agent Platform documentation this record's search passes surfaced separately, does not describe Agent Identity as a single, uniform capability available identically everywhere Google runs an agent. Agent Runtime, the managed runtime underneath Vertex AI Agent Engine and Agent Development Kit deployments, is the surface this record's corroborated search evidence most consistently describes as carrying Agent Identity at general availability. Gemini Enterprise Agent Platform is documented separately, and this record's search evidence was inconsistent on that platform's exact maturity level as of the 14 August milestone, with some material describing Agent Identity for Gemini Enterprise Agent Platform as still in preview even as Agent Identity generally is described as generally available. This record states that inconsistency rather than resolving it in either direction, because its own access to docs.cloud.google.com, where an editor could check the current, authoritative maturity label for each platform side by side, was blocked throughout this session. What this record does not do is describe Agent Identity as a single capability uniformly generally available across Agent Runtime, Gemini Enterprise Agent Platform, Vertex AI Agent Engine and Agent Development Kit deployments alike, because its own evidence does not support that collapse.

Google's own documentation also publishes a dedicated Agent Identity locations page, naming the specific regions where Agent Identity and its Auth Manager APIs are available. This record could not read that page's actual region list directly, because docs.cloud.google.com was blocked throughout this session, but the page's existence itself is evidence against inferring global availability from general availability status alone. A capability can be generally available, in the sense that Google no longer labels it Preview and extends it standard production support, while still being available only in a documented, bounded set of regions. This record treats general availability and global availability as two separate claims and does not conflate them.

A follow up verification pass run on 26 August 2026 surfaced a second, sharper example of the same discipline this record already applies to Agent Runtime versus Gemini Enterprise Agent Platform: Google's own guidance states plainly that the older IAM Connectors API, itself still labeled Preview, will not reach general availability at all, and directs a new project to the Agent Identity API instead and an existing project built on IAM Connectors to migrate. That is a documented case of a Preview labeled capability being retired rather than promoted, sitting immediately next to Agent Identity Auth Manager's own move to general availability, and this record states it as exactly that rather than treating every API in the Agent Identity family as converging on the same 22 August 2026 milestone. Search corroboration from this same pass also identifies the specific IAM role gating administrative control over AuthProvider resources, Agent Identity Editor, roles/agentidentity.editor, grantable at the project level. That confirms the administrative capability described throughout this record is a specific, assignable IAM role rather than an undifferentiated administrative power, and establishes nothing beyond that: it is not evidence that whoever holds that role was organizationally entitled to grant it to themselves or to anyone else, a distinction this record returns to in the ledger below.

The represented user: two different attributions, only one of them Google's to keep

Google's own material states that Agent Identity integrates with audit logging to provide clear audit logs both when an agent acts as itself and when it acts on behalf of an end user, and that when an agent acts on a user's behalf, logs can show both the agent's and the user's identities. This record verified that claim's shape consistently across independent search corroboration and treats it as real: Google's own Cloud Audit Logs, for actions the agent takes against Google Cloud resources and services, can carry both a principal field identifying the agent and a separate field identifying the represented user on whose behalf it acted.

What that dual attribution covers, precisely, is Google's own audit surface for actions the agent takes against Google Cloud itself. It is not, on anything reviewed for this record, a claim about what a third party API or SaaS system receives or retains once Auth Manager hands the agent a credential to reach it. A represented user attribution recorded in Google Cloud Audit Logs is Google's own evidence of its own mediation. Whether the external tool the agent then calls, using a credential Auth Manager retrieved, itself receives, logs or retains any signal distinguishing the agent from the represented user is a property of that external system, governed by whatever that system's own API and logging conventions are, not by Agent Identity or Auth Manager. This record keeps those two facts distinct rather than describing Google's own dual attribution as universal downstream provenance that follows the credential wherever it goes.

Auth Manager: a vault and a broker, not a permission system

Google's own documentation describes Agent Identity Auth Manager as a centralized credentials vault and authentication broker that simplifies outbound tool authentication for agents. Inside it, an operator configures AuthProvider resources, each defining an authentication type and the credentials for a specific third party application: an API key, a two legged OAuth client ID and secret for machine to machine access, or a three legged OAuth flow that lets an agent act using a delegated end user access token. Google's own material states the vault stores API keys, OAuth client secrets and user tokens in a Google managed store, which this record reads as the mechanism behind avoiding hardcoded secrets in an agent's own configuration, rather than as a claim about who is entitled to configure or retrieve what the vault holds.

Read precisely, Auth Manager answers a narrower question than the identity question Agent Identity answers. Agent Identity establishes which principal the agent presents as. Auth Manager establishes which stored third party credential a request for outbound authentication can retrieve, and under what configured conditions. Those are related questions and Google's own architecture connects them, through workloadIds and through the identity an agent presents when it queries the vault, but they remain two separate systems answering two separate questions, and this record treats a claim about one as a claim about the other only where Google's own documentation actually connects them.

A follow up verification pass run on 26 August 2026 found the same own authority versus delegated authority distinction stated again from a third surface, Agent Registry, the catalog through which an orchestrator agent discovers remote agents and Model Context Protocol toolsets. Google's own material states that when an orchestrator invokes a remote agent or an MCP toolset discovered through Agent Registry, it authenticates to the underlying service either using the agent's own Agent Identity or by having Auth Manager retrieve an API key or OAuth credential on its behalf. This record treats that as independent confirmation of the same architectural split described throughout this record, an agent acting under its own Agent Identity against an agent acting with a credential Auth Manager retrieved, rather than as a new distinction, because Agent Registry's own documentation does not describe a third authentication model beyond the two this record already verifies elsewhere.

Two different credential retrieval architectures, and Google does not describe them as one

This is the distinction this record found most consequential to keep precise, because collapsing it turns a documented, narrower guarantee into an undocumented, broader one. Google's own Auth Manager overview describes a specific retrieval flow for the direct, Agent Development Kit mediated path: a user triggers an event that requires the agent to authenticate to an outbound tool, the deployed agent, using the ADK, transparently intercepts that tool request, queries the Auth Manager vault, Auth Manager returns the secure credential, an API key or an OAuth token, to the agent, and the agent itself attaches that credential and invokes the external API. In that architecture, the agent process itself receives and handles the raw credential, even though the vault, rather than the agent's own configuration, is where the credential was stored.

Separately, Google documents a materially stronger property that applies specifically when Agent Identity is used together with Agent Gateway and Gemini Enterprise: end user credentials, such as those provisioned through a Gemini Enterprise connector, are encrypted by Auth Manager and only decrypted at the gateway, so that the agent itself can never access the raw credential. That is not the same architecture as the direct ADK mediated flow described above, and Google's own material does not present it as the same guarantee applied more broadly. This record states plainly which claim applies where: direct Auth Manager use through the ADK hands the agent the credential itself; Agent Gateway plus Gemini Enterprise keeps the credential encrypted until it reaches the gateway and never lets the agent see it raw. This record found no documentation extending the gateway level guarantee to Vertex AI Agent Engine or plain ADK deployments that are not also sitting behind Agent Gateway, and does not assert one.

Organization Policy: enforced at configuration time, on a documented set of fields

Google Cloud's Organization Policy Service supports custom constraints scoped specifically to the AuthProvider resource type under agentidentity.googleapis.com, applicable to CREATE and UPDATE operations, and capable of denying an operation that violates the constraint's condition. This record's search corroboration surfaced a concrete, worked example Google itself documents: a custom constraint that denies the creation of a new three legged OAuth AuthProvider that does not have PKCE, Proof Key for Code Exchange, enabled. That is real, checkable, configuration time enforcement, verified across independent search corroboration in consistent terms, though this record's own inability to fetch docs.cloud.google.com directly means the exact YAML condition syntax was not read firsthand in this session.

This record's search corroboration also surfaced field names associated with these custom constraints, including allowedScopes, blockedScopes, workloadIds, and configuration fields specific to the three legged OAuth flow, an authorization URL, a client ID, a continue URI, PKCE configuration and a token URL, alongside two legged OAuth's own client ID and token URL fields and generic description and name fields. What this record could not independently confirm, because it could not read the underlying custom constraint reference page directly, is the precise operational semantics of allowedScopes and blockedScopes: specifically, whether they constrain which OAuth scopes an AuthProvider may be configured to request at creation or update time, or whether they reach further into which scopes an already issued token may carry or which scopes a specific agent identity may retrieve through that provider at runtime. This record states what is confirmed, that these fields exist and gate AuthProvider CREATE and UPDATE operations, and leaves their exact scope of enforcement undocumented rather than assuming the broader, more consequential reading.

What this record states with more confidence, because it follows directly from the mechanism Organization Policy custom constraints are documented to use everywhere else in Google Cloud, is what this enforcement is not. A constraint that denies creating or updating an AuthProvider is a gate on configuration, evaluated when an administrator or an automated deployment tries to create or change that resource. It is not evidenced anywhere reviewed for this record as a gate evaluated at the moment a specific agent attempts a specific downstream action using a credential that AuthProvider already produced. Authority over how an AuthProvider may be configured, authority to retrieve a credential from an already configured AuthProvider, and authorization of the specific consequential action a credential is then used for, are three separate layers, and this record does not let evidence for the first stand in for the other two.

Policy inheritance, and what this record does not infer about it

Organization Policy in Google Cloud is documented, as a general platform property well established outside Agent Identity specifically, as applicable at the organization, folder or project level and inherited down the resource hierarchy unless a more specific policy overrides it. This record treats that general inheritance model as applying to AuthProvider custom constraints in the same way it applies to every other custom constraint Google Cloud supports, because nothing reviewed for this record describes AuthProvider constraints as an exception to that general mechanism. What this record does not infer, because nothing reviewed states it, is that changing an organization policy after an AuthProvider already exists and a three legged OAuth token has already been issued causes that already issued token's scopes to narrow retroactively. Organization Policy, on the evidence available here, governs what configuration is allowed to be created or changed going forward. It is not documented, anywhere this record could verify, as reaching back to constrain a credential a third party OAuth provider has already granted.

Principal Access Boundary: a resource ceiling evaluated alongside IAM, not a per-action gate

A follow up verification pass run on 26 August 2026 surfaced Principal Access Boundary, PAB, as a distinct control Google's own material describes as fully integrated with Agent Identity alongside IAM and VPC Service Controls, separate from the AuthProvider custom constraints described above. A PAB defines the set of resources a principal, an Agent Identity among them, is eligible to access at all, and IAM then evaluates that boundary together with the principal's existing allow and deny policies before a request is permitted to reach a resource. Search corroboration consistently frames PAB as a firewall for identities: it narrows what a principal can reach regardless of what a specific IAM allow policy would otherwise permit on its own, rather than adding a new grant of its own. Read precisely, that makes PAB a ceiling on which resources are reachable, evaluated at the moment a request is authorized against a resource, not a check over whether the particular operation that request represents was the one a person or an administrator actually intended in that moment. A PAB that leaves a given Cloud Storage bucket inside an Agent Identity's boundary says nothing about whether a specific write to a specific object inside that bucket was the action anyone authorized; it says only that the bucket itself was within the boundary the identity was allowed to reach at all. This record keeps that distinction because it recurs at every other layer of this architecture: PAB narrows the resource surface an Agent Identity can touch, and this record found nothing documenting it as a decision about a specific consequential action taken on a resource already inside that surface.

Context Aware Access: what is bound, and what replay resistance actually proves

Google's own material, corroborated consistently across this record's search passes, states that a default Context Aware Access policy for Agent Identity enforces mutual TLS to Agent Gateway and DPoP, Demonstrating Proof of Possession, binding on the agent's own access token, with the combined effect that a certificate bound token cannot be used from outside its own trusted runtime, such as the specific Cloud Run container it was issued to. Google documents this as making stolen, bound credentials unreplayable, which this record reads precisely: the property being defended is token theft and replay from a different location than the one the token was issued to, not a broader claim about the legitimacy of what the token's holder does with it from inside that trusted runtime. Google's own material also documents an opt out, for specific token sharing requirements among agents or where an agent cannot handle a 401 Unauthenticated challenge, and states plainly that opting out removes token binding protection and leaves the resulting short lived access token vulnerable to theft or replay. This record treats replay resistance as real, checkable protection against a specific theft and reuse scenario, and does not treat it as evidence that a given use of the token, from inside its own bound runtime, was within any particular task or mandate.

A follow up verification pass run on 26 August 2026 sharpened where each of those two binding mechanisms actually applies, and this record keeps them separate rather than treating both as one uniform property of every Agent Identity token. Mutual TLS, bound to the agent's own X.509 certificate, is the mechanism search corroboration consistently places at first party access to Google Cloud APIs and to Agent Gateway itself. DPoP is the mechanism the same corroboration places specifically at interactions that continue beyond Agent Gateway, where a separate authorization token is additionally tied to the agent's certificate and signed with a key pair Agent Identity manages. Search corroboration describes the combination, mTLS at the gateway and DPoP beyond it, as producing a double bound credential, and this record states that combination as exactly that, a description of where two distinct binding mechanisms are documented to apply along one request path, rather than as evidence that every Agent Identity Auth Manager tool invocation, including the direct API key and OAuth retrieval paths described earlier in this record, itself uses DPoP. Nothing this record reviewed extends DPoP binding to Auth Manager credential retrieval outside the Agent Gateway path specifically.

Revocation: what is documented, and what remains unstated

This record searched specifically for what actually terminates when an operator revokes an IAM grant, deletes an Agent Identity, modifies or deletes an AuthProvider, changes an organization policy, revokes an OAuth token or its refresh token, or removes a represented user's consent, and for what happens to a cached credential, an already issued access token, a refresh token, an active agent session or an in flight external request when any of those actions occurs. Google's own material, as corroborated across this session's search evidence, documents the existence of these controls, deleting an Agent Identity, modifying or deleting an AuthProvider, revoking an IAM grant, without documenting, in anything this record could verify, the precise propagation semantics: whether a credential Auth Manager already returned to an agent, or a token an agent is already holding mid session, is immediately invalidated by that action, or whether it simply cannot be renewed and continues to work until its own natural expiry. This record does not assume the stronger, more protective reading. Where Google's own material states a specific propagation behavior, this record reports it. Where it does not, this record records the gap as undocumented rather than resolving it either way, consistent with how Moona Intelligence has already treated the same open question in Okta's Cross App Access architecture.

A follow up verification pass run on 26 August 2026 did surface one specific propagation mechanic, for the AuthProvider resource itself rather than for a credential already retrieved through it. Google's own material states that deleting an AuthProvider disables it and places it into a soft delete state for 30 days, during which it can be restored, after which its underlying policy is purged roughly one additional day later, at which point a new AuthProvider can be created under the same name. That is a specific, checkable retention and restore window for the configuration object itself, and this record reports it as exactly that. It is not, on the same evidence, a statement about whether a credential Auth Manager already handed to an agent, or an access token already issued, continues to function during that 30 day soft delete window, which this record still finds undocumented and does not resolve by inference from the retention window alone.

Challenge authority and recovery: neither found documented here

This record searched for a mechanism by which a human approver, a step up authorization prompt, an administrator or another party could challenge or hold a specific proposed consequential action an agent is about to take through a credential Auth Manager retrieved, distinct from an organization policy that can deny creating or modifying an AuthProvider before any credential exists. It found none in anything reviewed here. A denied AuthProvider creation, the PKCE example above among them, is a real and specific control, and this record does not describe it as an action level human approval gate, because it operates before a credential exists rather than at the moment an already issued credential is about to be used. Google's own separately documented Semantic Governance Policy check inside Agent Gateway, verified in Moona Intelligence's own earlier coverage of execution authority, is the closer analogue to an action level gate, and this record treats it as a distinct capability rather than folding its evidence into Agent Identity or Auth Manager's own documented scope. This record also searched for a generic mechanism, documented anywhere in Agent Identity or Auth Manager's own material, for reversing an external tool action after it has already executed. It found none. Revoking an identity, a credential or an AuthProvider is documented. Undoing what an already executed external action did is not, and this record preserves that as undocumented rather than inferring a recovery path from the existence of revocation controls.

The Authority Provenance ledger

Multiple distinct actors sit inside this architecture, and this record does not collapse them into one generic user. The Google Cloud organization administrator, or whoever holds the IAM permission to configure Organization Policy, sets the outer boundary on what AuthProvider configurations may exist at all. A separate Agent Identity or AuthProvider administrator, who may or may not be the same person, actually creates and configures a specific AuthProvider, including which agent identities its workloadIds field names. A developer deploys the agent itself, binding it to an Agent Identity through Agent Runtime, Vertex AI Agent Engine or Gemini Enterprise Agent Platform. An end user, where a three legged OAuth flow is used, personally completes an OAuth consent screen that produces the delegated token Auth Manager subsequently vaults. The represented user, whose identity an agent's audit log entry may carry alongside the agent's own, is not always the same person as the one who completed that OAuth consent. The agent itself is the technical principal that queries Auth Manager and, in the direct ADK path, handles the resulting credential. A third party OAuth provider, outside Google entirely, is the party that actually issues the delegated token and decides what its own consent screen discloses to the end user completing it. And an external resource owner, whoever administers the third party system the credential ultimately reaches, independently enforces whatever access control that system applies once a request arrives carrying the credential. This record keeps all of those distinct rather than describing any one of them as simply the user.

Authority grantor. Layered, not singular. Google IAM proves that a specific technical principal held the permission to create or modify an Agent Identity or an AuthProvider. A three legged OAuth consent screen proves that a specific end user clicked through and authorized that particular delegation to that particular AuthProvider. Neither is documented, anywhere reviewed for this record, as proof that the configuring administrator held the organizational, contractual or resource ownership mandate to grant every consequential capability that configuration eventually makes available, or that the consenting end user was the person organizationally entitled to authorize the specific downstream use the credential is later put to.

Mandate or basis. Undocumented. Successful IAM authentication proves a principal held a technical permission. OAuth consent proves a user clicked through a specific authorization screen. Neither, on the evidence available here, establishes that the administrator or the consenting user held a deeper organizational entitlement, a resource ownership right, a fiduciary duty or a contractual basis to make that specific delegation. This record does not infer legitimacy from successful authentication, IAM membership or OAuth consent alone, and records this layer as undocumented rather than assumed.

Delegated scope. Documented, but split across several distinct systems rather than one unified permission. Google IAM permissions assigned to the Agent Identity itself govern what the agent may do against Google Cloud resources directly. AuthProvider configuration and its allowedScopes, blockedScopes and workloadIds fields, to the extent this record could confirm their operational reach, govern what an outbound third party credential may be configured to request and which agent identities may retrieve it. The third party OAuth provider's own granted scope, established at the moment of consent, governs what the resulting delegated token can actually do against that external system. Represented user authority, where Google's own audit dual attribution applies, is a logging property inside Google's own systems, not itself a grant of scope. This record keeps these four layers separate rather than describing them as one generic agent permission.

Explicit limits. Attributed to the specific layer that actually enforces each one, rather than pooled together. IAM enforces what the Agent Identity principal may do against Google Cloud resources. Principal Access Boundary constrains which resources an Agent Identity is eligible to reach at all, evaluated by IAM together with allow and deny policies, a ceiling on the reachable resource surface rather than a decision about a specific action inside it. Organization Policy custom constraints enforce what an AuthProvider may be configured to look like at creation or update time, the PKCE example among them. Context Aware Access enforces that a bound access token cannot be replayed outside its issuing runtime, by default, through mutual TLS at Agent Gateway and DPoP for interactions that continue beyond it. Auth Manager enforces which stored credential a given retrieval request may receive. Agent Gateway, where it sits in front of Agent Identity and Gemini Enterprise together, additionally enforces that the agent itself never receives a raw end user credential. The third party OAuth provider enforces whatever scope it granted at consent time. The downstream resource server enforces whatever authorization model it runs internally once a request carrying the credential arrives. This record attributes each limit to the layer that actually enforces it rather than treating Agent Identity as though it enforces all of them.

Inherited permissions or assumptions. Not established as an intersection, a narrowing or a widening, because nothing reviewed for this record states the composition rule explicitly enough to call it verified. When an agent acts on a represented user's behalf, Google's own material documents that the audit trail can show both identities and that Agent Identity itself carries its own IAM permissions, separate from the represented user's own. What effective permission the agent actually operates under in that moment, the user's own downstream authority, a narrower scope Auth Manager retrieved, some intersection of the two, or Agent Gateway policy layered on top, is not stated as a single composition rule anywhere this record could verify. This record does not assume an intersection merely because that would be the more conservative or more expected design, and records the composition rule as undocumented.

Revocation or modification. Documented as existing, with one concrete propagation window and otherwise undocumented as to propagation. Deleting an Agent Identity, modifying or deleting an AuthProvider, revoking an IAM grant and changing an organization policy are each documented, real controls. Deleting an AuthProvider specifically is documented with a 30 day soft delete and restore window, followed by policy purge roughly a day later. What none of these controls documents is what happens, during or after that window, to a credential already retrieved, a token already issued, a refresh token, an active agent session or an in flight external request in progress at the moment of revocation. This record does not equate the existence of a revocation control, or a documented retention window for the configuration object itself, with an established guarantee that it reverses what has already been granted or already executed.

Challenge authority. Undocumented, for the specific case of an already proposed consequential action. An Organization Policy denial at AuthProvider creation or update time is real and this record does not diminish it, but it is a configuration time gate, not a mechanism by which a human approver, an administrator or a step up authorization step can hold or challenge a specific proposed action once an agent already holds a valid credential. Nothing reviewed for this record names one at that layer.

Recovery. Undocumented. Nothing reviewed for this record describes a generic mechanism, inside Agent Identity, Auth Manager, Organization Policy or Context Aware Access, for reversing an external tool action once it has already executed with a credential that was valid at the time it was used. Identity and credential revocation are real controls over what happens next. They are not documented as controls over what has already happened.

Provenance evidence quality. Layered, and stronger at the identity and credential access layers than at the mandate or execution authority layers. The existence, general availability dates, SPIFFE and X.509 attestation mechanism, the 24 hour certificate lifetime and automatic renewal, service account comparison, Principal Access Boundary's resource ceiling semantics, Context Aware Access token binding and represented user dual attribution are each corroborated consistently across repeated, independently phrased search passes drawing on Google's own documentation, run across sessions on both 24 August and 26 August 2026, though this record's own direct fetch access to docs.cloud.google.com was blocked on every attempt in both passes, which keeps every one of those claims at manual review rather than independently verified against the raw page. The Auth Manager credential retrieval flow, both the direct ADK mediated path and the distinct Agent Gateway plus Gemini Enterprise encrypted path, the Organization Policy PKCE denial example, and the AuthProvider 30 day soft delete and restore window, are similarly corroborated in specific, consistent terms rather than a single vague summary. What remains weakly evidenced, across every layer of this architecture, is exactly what remains weakly evidenced in every comparable system Moona Intelligence has reviewed: the administrator's or the end user's own underlying organizational entitlement to grant what they technically had the permission to grant, a runtime challenge mechanism over a specific proposed action, and a recovery path once that action has already executed. Strong new evidence at the identity and credential layers does not convert into evidence at those remaining layers, and this record does not let it.

Where this sits against Moona's own coverage

GitLab's composite identity answers a related but narrower question inside one product: the intersection of a human role and a service account role, resolved once, at the moment access is checked. Google's architecture is broader and more layered, a first class identity primitive plus a separate credential vault plus a separate policy layer plus a separate gateway, and this record has kept each layer's evidence distinct rather than crediting Agent Identity with guarantees that actually belong to Agent Gateway or Context Aware Access. Uber's own actor chain architecture, already verified in Moona Intelligence's own coverage, carries a human user's identity and each intermediate agent's identity through a chain of short lived tokens in production, which is closer in shape to what Google's represented user audit attribution documents than to what any single vendor's identity primitive alone establishes, and both leave the same mandate question open: proof of who technically constituted an authorization chain is not proof that the constituting party held the organizational mandate the chain implies. Okta's Cross App Access and the Model Context Protocol's own Enterprise Managed Authorization extension answer the adjacent, upstream question of whether a requesting application may reach a resource application for a user at all, resolved by an administrator's standing policy rather than by an identity primitive, and this record's own finding, that an administrator's technical capability to configure a policy is documented everywhere while the administrator's organizational entitlement to do so is documented nowhere, holds again here, for Google's own AuthProvider configuration. Rubrik's Agent Identity, a differently named but conceptually adjacent product, mints a scoped token only after a specific tool call has already cleared policy, an execution time design that Google's own Organization Policy custom constraints for AuthProvider do not attempt, because Google's constraints operate at configuration time instead. Google's own Agent Gateway Semantic Governance Policy check, verified separately in Moona Intelligence's earlier coverage of execution authority, is the part of Google's own stack that actually does evaluate a specific proposed action against user intent before it is dispatched, and this record deliberately keeps that evidence in its own place rather than importing it into Agent Identity or Auth Manager's documented scope, because neither of those two systems is documented as performing that check itself.

Four independently arrived at architectures, a Git platform's composite role intersection, a ride hailing platform's actor chain token architecture, an identity platform's cross application access protocol, and now a cloud platform's own IAM identity and credential broker, keep landing on the same undocumented layer from four different starting points. Each proves, with real and checkable evidence, who technically configured an authorization, who technically holds a resulting credential, and in Google's case, whose identity an audit log can name alongside an agent's own. None of them, including this one, proves that the configuring party was organizationally entitled to grant what the configuration produced, or that a specific consequential action an agent took, using a credential that was validly issued to it, was actually inside the task or the mandate a person or an organization legitimately constituted for that agent. Google Cloud has made real, verifiable progress on the identity and credential layers of that chain. It has not, on anything this record could verify, closed the gap underneath them.