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.

CrowdStrike's Agentic IdP: the same split, reached from a different starting point

Three CrowdStrike dates matter here, and this record keeps them apart rather than collapsing them into the day it was updated. CrowdStrike unveiled Continuous Identity for AI Agents on 15 June 2026 at Identiverse 2026, a real time authorization capability built on technology from its acquisition of SGNL, already verified in full in Moona Intelligence's own Somansa Privacy-i AIDR record. CrowdStrike unveiled Falcon Guardian on 1 September 2026 at Fal.Con 2026, an endpoint runtime capability for discovering and containing AI agent activity on managed Windows and macOS machines, also already verified there. CrowdStrike introduced the Agentic IdP on 2 September 2026, also at Fal.Con 2026. This record's own verification date is 3 September 2026, the current Moona Radar date, and this record does not describe Continuous Identity as new on 2 September, does not describe Falcon Guardian as the Agentic IdP, and does not treat its own 3 September verification date as a CrowdStrike publication date.

Independent search corroboration frames Agentic IdP's own contribution precisely: it fills a gap Continuous Identity itself did not close. Continuous Identity, on this record's own reading and on Moona Intelligence's earlier verification of it, answers the authorization question, whether a specific action a specific agent is attempting should be granted, denied or revoked in real time. It does not, on anything reviewed for either record, answer the prior question of what establishes that the thing presenting itself as an agent to be authorized is a specific, trustworthy, non spoofable principal in the first place, as opposed to a shared service account, a duplicated credential or an unregistered process. Agentic IdP is CrowdStrike's own answer to that prior question, and this record reads it as structurally the same move Google Cloud already made: a first class identity primitive, verified separately from and prior to the credential and authorization layer sitting on top of it. Google split that into Agent Identity and Auth Manager. CrowdStrike splits it into Agentic IdP and Continuous Identity. Two vendors, a cloud platform and a security incumbent, arrived at the same architectural shape independently, which this record reads as evidence the underlying distinction, identity provenance is a prerequisite for authority, not a substitute for it, is a real market pattern rather than one company's framing choice.

Registration, not universal discovery

CrowdStrike's own material, as corroborated consistently across this record's search passes, states that Falcon Guardian discovers known and shadow AI agents across the enterprise and that Agentic IdP registers each one, the moment it comes online, into what CrowdStrike describes as a single authoritative directory. Read precisely, that sentence names a specific discovery surface rather than a universal one. Moona Intelligence's own prior verification of Falcon Guardian, in the Somansa Privacy-i AIDR record, already established that Guardian's own confirmed architecture covers managed Windows and macOS endpoints running the Falcon sensor, and found no material extending Guardian's own discovery to an agent that runs entirely in a remote or cloud hosted environment, a SaaS hosted agent, a browser mediated interaction, or a remote Model Context Protocol server. This record does not assume Agentic IdP's own registration reaches further than the discovery surface feeding it, and states plainly what it could not confirm: whether an agent that never touches a Falcon sensor managed endpoint, such as one running purely inside a cloud workflow or a third party SaaS platform, can be registered into the same authoritative directory by some other documented path, or whether Guardian's own discovery is the only route in. Nothing this record could reach names a second registration path, and this record does not invent one. A single authoritative directory that only some agents can actually reach is a narrower, still consequential claim than a directory covering every agent an enterprise runs, and this record states the narrower claim.

This record also could not confirm, from anything it could reach, how automatic registration handles a duplicate: two processes presenting as the same agent, an agent redeployed under a new version, or a second instance of the same agent type running concurrently. CrowdStrike's own material states registration happens automatically when an agent comes online, without stating the matching or deduplication logic behind it, and this record records that mechanism as undocumented rather than assumed.

What one logical agent actually is: CrowdStrike's own instance argument

This is the sharpest, most specific technical claim this record found in CrowdStrike's own material, and it comes from a CrowdStrike blog post, corroborated across independently phrased search passes converging on consistent wording, dated 24 June 2026, nine days after Continuous Identity's own unveiling and well before Agentic IdP itself existed as a named product; this record treats it as background architectural reasoning CrowdStrike had already published, not as Agentic IdP's own launch material, and states that date distinction explicitly. The blog's own argument, read precisely: RFC 9068, the standard defining claims for JWT formatted OAuth access tokens, specifies a subject, a client and a scope, designed for a single principal scenario, and defines no claim for an agent's own instance identity. When an OAuth access token is issued to a user, the client identity, meaning the agent's own identity, is encoded in the token's client_id field, but client_id names the registered client application, the type of agent, such as a specific coding assistant product, not a specific running instance of it. CrowdStrike's own material states that distinction matters because the same client software can be running substantially different tasks for many different users at once, each instance carrying a potentially different set of permissions, and that within an AI workflow it is the instance, the human on whose behalf it acts, and the relationship between the two that needs to be identified, not merely the application type.

CrowdStrike's own material goes one step further, and this record treats this as the specific, checkable answer to the canonical agent identity question this record has asked of every architecture it has reviewed: what actually constitutes one logical agent. In a conventional RESTful architecture, an instance is a specific running process, the kind of thing a load balancer distributes traffic across. CrowdStrike's own material states that because an AI agent needs to maintain conversation context across multiple interactions, instance is better understood there as a logical concept, a specific ongoing task or session, rather than a particular running process. Read against Agentic IdP's own registration claim, this record does not find a direct statement connecting that instance definition to what Agentic IdP's own directory actually keys a registered identity to, a specific agent definition, a deployed version, a running process or a task scoped session, and does not assume the blog's own conceptual framing is the literal registration key Agentic IdP implements. What this record does state, because CrowdStrike's own material states it plainly, is that CrowdStrike has published a specific, checkable position on why a client or application level identity is not sufficient, a client_id names a type, not an actor, and that the identity gap CrowdStrike built Agentic IdP to close is framed, in CrowdStrike's own words, at the level of a task or session rather than a person's account or an installed application alone.

Cryptographic identity: documented as unspoofable, not documented as SPIFFE

CrowdStrike's own material, corroborated consistently across search passes, states each agent is issued a cryptographically verifiable identity that cannot be spoofed or shared, and that only an agent holding one is eligible for the downstream authorization decision. This record credits that claim precisely as CrowdStrike states it and no further. Continuous Identity's own June material, already verified in the Somansa Privacy-i AIDR record, explicitly names the SPIFFE standard as the basis for the cryptographically verifiable identity it assigns to each agent. Nothing this record could reach, across repeated, independently phrased search passes specifically testing for this connection, states that Agentic IdP's own September identity mechanism is the same SPIFFE based attestation, as opposed to a related but separately implemented cryptographic scheme feeding the same directory. This record does not transfer June's documented SPIFFE property onto September's product on the strength of both coming from CrowdStrike, the same discipline it has already applied throughout this record to Google's own Agent Identity, Auth Manager, Agent Gateway and Agent Registry as four related but separately evidenced systems. What this record states is precisely two separate facts: Continuous Identity's cryptographic identity mechanism is documented as SPIFFE based. Agentic IdP's cryptographic identity mechanism is documented as unspoofable and unshareable, with the exact underlying mechanism, SPIFFE or otherwise, undocumented in anything this record could reach.

Tokens: scoped to a task, not shown to be scoped to one action

CrowdStrike's own material states Agentic IdP brokers access through tokens scoped to the minimum access, for the minimum time, required for each task, and that agents are never given standing credentials of their own. This record credits the shape of that claim, a broker minting bounded access on demand rather than an agent holding a durable key, as real and consistent with the same architecture Continuous Identity's own Zero Standing Privilege model already describes. It does not extend the claim further than CrowdStrike's own wording supports. Scoped to the minimum access a task requires is a claim about a task, not a claim about a single action inside that task, and nothing this record could reach states that a brokered token is exact action bound, single use, or invalidated the instant one specific tool call inside a broader task completes. A token that is short lived and scoped to one task can still, on the evidence available here, remain valid standing access across several distinct actions inside that task's own lifetime, which is a materially different and weaker guarantee than an exact action token, and this record states the documented claim, task scoped and time bounded, rather than the stronger, unproven one.

Standing identity is not standing resource privilege

This record keeps two claims separate that CrowdStrike's own material and the Zero Standing Privilege framing around it can otherwise blur together. An agent's own registered identity inside Agentic IdP's authoritative directory is, on CrowdStrike's own account, durable: the agent is registered once, the moment it comes online, into a directory meant to persist as the canonical record of that agent's existence. That is a standing identity. Separately, CrowdStrike's own material states the agent is never given a standing credential of its own, that resource access is instead brokered fresh, minimally scoped and time bounded, for each task. That is the absence of standing resource privilege. The two are not the same claim, and a canonical, persistent agent identity in a directory can coexist with zero standing privilege over any actual resource, exactly as this record's own reading of Google's Agent Identity, tied to the lifecycle of its hosting resource rather than reissued per request, already treats identity persistence and credential minimality as two separate properties rather than one. This record states both halves of CrowdStrike's own claim rather than the version that only asserts the second half.

Human or workload attribution: bound, not itself a mandate

CrowdStrike's own material states every action an agent takes is bound to the human or workload it acts on behalf of, so that activity traces back to an accountable party. This record reads that precisely against the same distinction it has already drawn for Google's own represented user audit attribution above: proving which human or workload an agent's action is bound to is actor provenance, real, checkable evidence of who the action traces back to. It is not, on anything CrowdStrike's own material states, proof that the identified human or workload was organizationally entitled to authorize the specific action the agent then took. This record found no CrowdStrike material naming an originating task, ticket, workflow or resource owner grant as a further input Agentic IdP itself carries, and does not infer one. Nor did this record find a specification of the technical mechanism carrying that binding, whether it rides inside a token's own claims, a directory relationship, or a separate audit record CrowdStrike's own platform maintains alongside it, and states that mechanism as undocumented rather than assumed.

Delegation: Continuous Identity's own claim, not a new one from Agentic IdP

Search corroboration surrounding this launch repeats a framing already familiar from Continuous Identity's own June material: that traditional identity providers force organizations to represent agents as service accounts, API keys and workload identities, static models CrowdStrike says were never built for identities that act autonomously and delegate to sub-agents. This record does not find, in anything specific to Agentic IdP's own registration and directory claims, a delegation or sub-agent propagation mechanism distinct from the one Continuous Identity already documents and this record's own Somansa Privacy-i AIDR coverage already ledgers in full: caller and ownership context preserved through a delegation chain rather than reset at each hop, with whether a sub-agent's delegated scope is a verified subset of its parent's own scope, whether a sub-agent may itself redelegate, and whether delegation depth is bounded, each already recorded there as undocumented. This record does not duplicate that ledger here and does not manufacture a second, Agentic IdP specific delegation claim from adjacent marketing language describing the general problem Agentic IdP and Continuous Identity together are built to solve.

Revocation and challenge: named as a model, not shown as a mechanism

CrowdStrike's own material, corroborated across search passes, describes Continuous Identity's own access decision as dynamic, granting access the moment it is needed and revoking it the moment it is not. This record does not find, in anything specific to Agentic IdP itself, a separate statement about what happens to an agent's own registered directory entry, as opposed to a brokered resource token, when an agent is deregistered, decommissioned or found compromised: whether deregistration is immediate, whether it propagates to a credential a broker already issued, or whether an in flight action already underway at the moment of deregistration can still complete. This record states each as undocumented rather than inferred, consistent with how it already treats AuthProvider and Agent Identity revocation propagation for Google above, and found no mechanism, in anything specific to Agentic IdP, by which a human approver could challenge or hold a specific registration or a specific brokered token before it is used, distinct from Falcon AIDR's own separately documented, machine driven behavioral revocation trigger already covered in the Somansa Privacy-i AIDR record.

Agentic IdP's Authority Provenance ledger

Moona Intelligence applies the same nine dimensions to Agentic IdP that this record applies to Google's own Agent Identity and Auth Manager above, kept as its own ledger because nothing this record could reach documents Agentic IdP, Continuous Identity and Falcon Guardian as one integrated decision.

Authority grantor. Undocumented beyond an enterprise's own Falcon administrator and whatever deployment process brings an agent online. CrowdStrike registering an agent the moment it appears is not evidence that the party who deployed it, or the administrator who configured Falcon Guardian's own discovery policy, held organizational legitimacy to bring that specific agent into existence with the access it was later brokered, and this record states grantor legitimacy as unknown, the same reading it applies to Google's own AuthProvider administrator above.

Mandate or basis. Undocumented. Registration proves an agent came online and was discovered. It does not, on anything this record could verify, establish an originating task, ticket, workflow or resource owner grant behind the access that agent is later brokered, and this record does not infer one from registration or from human or workload attribution alone.

Delegated scope. Documented at the level CrowdStrike's own material actually states it: tokens scoped to the minimum access, for the minimum time, a task requires. This record does not extend that to a specific resource, API, tool argument or a single bounded action, because CrowdStrike's own wording names a task as the unit, not a narrower one, and does not assert exact action binding CrowdStrike's own material does not claim.

Explicit limits. A registered identity gate, only a trusted, registered agent is eligible for downstream authorization, paired with a time and task bounded token broker. This record attributes the identity gate to Agentic IdP and the subsequent per action decision to Continuous Identity, and does not attribute either capability's own enforcement to the other absent a specific statement that the two are evaluated as one decision.

Inherited assumptions. Agentic IdP's own framing targets a version of the same collapse this record has named at every other layer: that discovery is treated as trust, that registration is treated as authorization, and that a cryptographically valid identity is treated as proof an action is permitted. CrowdStrike's own material, stating that only a trusted, registered identity is eligible for authorization, correctly separates registration from the authorization decision itself rather than collapsing them, which this record credits as a sound architectural distinction. What remains unproven is the further, unstated assumption a reader could otherwise draw from that same architecture: that a human or workload's own attribution to an agent's action is equivalent to that human or workload having been entitled to authorize it, a distinction this record does not find CrowdStrike's own material asserting, and does not find it denying either.

Revocation or modification. Documented for Continuous Identity's own access decisions as dynamic. Undocumented, in anything specific to Agentic IdP itself, for what happens to an agent's own directory registration, or to a token a broker already issued, at the moment an agent is deregistered or found compromised, and this record does not assume instant propagation absent a specific claim that it is.

Challenge authority. Undocumented, in anything specific to Agentic IdP, as a human facing approval step over a specific registration or a specific brokered token before it is used. Falcon AIDR's own machine driven behavioral revocation trigger, already verified in the Somansa Privacy-i AIDR record, is a distinct capability this record does not import into Agentic IdP's own documented scope absent a specific statement connecting the two.

Recovery. Undocumented. Nothing this record could reach describes a mechanism, inside Agentic IdP, Continuous Identity or Falcon Guardian, for reversing an external effect a brokered token already produced before revocation or deregistration occurred.

Provenance evidence quality. Medium. Agentic IdP's own existence, its 2 September 2026 introduction at Fal.Con 2026, its registration, directory, cryptographic identity, token brokering and human or workload attribution claims, and its own stated relationship to Continuous Identity as the capability that fills a gap in real time authorization, are corroborated across repeated, independently phrased search passes converging on consistent wording from CrowdStrike's own investor relations mirror and syndicated wire coverage, though every direct fetch of crowdstrike.com and ir.crowdstrike.com was blocked in this session, which keeps every one of those claims at manual review rather than independently verified against the raw page. The instance as a logical, task or session scoped concept, distinct from a running process, is corroborated across multiple passes from a single CrowdStrike blog post dated 24 June 2026, published before Agentic IdP itself existed as a named product, and this record treats it as CrowdStrike's own background architectural reasoning rather than as Agentic IdP's own launch material. Unknown for the exact registration matching and deduplication mechanism, for whether an agent outside Falcon Guardian's own managed endpoint discovery surface can be registered by any other documented path, for whether Agentic IdP's own cryptographic mechanism is the SPIFFE based attestation Continuous Identity documents, for exact token format and replay behavior, and for revocation propagation timing specific to a directory registration rather than a Continuous Identity access decision. An editor with unblocked access to CrowdStrike's own Agentic IdP product documentation should confirm the mechanics above directly before any claim in this section is relied on beyond the manual review level recorded here.

The IAM MCP server: mutation reaches the permission environment itself

Every capability verified above, Agent Identity, Auth Manager, Principal Access Boundary, Context Aware Access, Organization Policy and Agent Registry, governs how an agent acts through IAM: which principal it presents as, which credential it retrieves, and what that credential is allowed to reach. Google Cloud's own IAM release notes date a materially different capability, the IAM remote MCP server, to general availability on 10 September 2026: a Model Context Protocol server that lets a connected AI application inspect and manage custom IAM roles and deny policies themselves. This record reads that distinction precisely. Everything else in this record's own architecture is an agent acting within a permission environment IAM has already set. The IAM MCP server is a tool surface for changing that environment, the roles and deny policies that decide what any principal, human or agent, may do next. That is meta-execution: an action whose consequence is not a resource being read or written, but the rules governing later resource access being read or written.

Google's own usage guide for the IAM remote MCP server, read directly, states it connects AI applications, naming Gemini CLI, ChatGPT and Claude specifically, so they can inspect and manage custom roles and deny policies across a project, folder or organization, and names the specific IAM roles a caller needs: MCP Tool User to reach the server's tools at all, Role Administrator to manage custom roles, and Deny Admin to manage deny policies. The same guide recommends using a separate identity for agents rather than a human operator's own credentials, and states that Google's MCP servers generally provide fine grained authorization, scoped to the specific tool an identity may call, and centralized audit logging. Read precisely, that is real, checkable governance over which technical identity may reach which tool on this server, the same identity and access layer this record has already verified Agent Identity and Auth Manager provide elsewhere in Google's own stack. It is not, on anything this record reviewed, a statement that a specific call one of those tools makes was itself inside a mandate a person or an organization actually granted for that exact change.

Google's own MCP reference for iam.googleapis.com, also read directly, documents what the server's tools actually do once called, in terms specific enough to check. create_deny_policy and update_deny_policy create or modify a deny policy, an explicit prohibition Google's own reference states overrides allow policies, including inherited allow policies, so a deny rule set through this server can block access an otherwise applicable allow policy, at any level of the resource hierarchy, would otherwise grant. delete_deny_policy permanently deletes a deny policy, after which, in Google's own words, its rules no longer restrict access for the principals they named. delete_role deletes a custom role, after which existing IAM bindings that used it stop granting the access they granted. Each of those three is a documented, checkable before and after state change to the permission environment itself, not to a resource inside it.

Applying this record's own standard precisely: technical permission to call these tools is not the same fact as legitimate authority for the specific permission state transition a given call produces. Holding MCP Tool User, Role Administrator and Deny Admin is the documented gate on who may call create_deny_policy, update_deny_policy, delete_deny_policy or delete_role. Nothing in Google's own material reviewed for this update documents a required human approval step before one of those calls executes, a check binding the call to the exact before and after policy state, the affected principals, resources and environment, and the objective or delegation that was supposed to authorize it, or a check that the agent's current execution state, what it has already done in this session, warrants this specific mutation now. Nor does anything reviewed document a self constraint preventing an agent holding Deny Admin from deleting the very deny policy that was meant to restrict its own later actions, or from creating a deny policy that narrows a different principal's access instead. This record does not infer that such a mutation has occurred or that Google's own default configuration permits it unsupervised; it states plainly that mandatory human approval, legitimate delegation validation and self constraint protection are each undocumented in the material reviewed, the same standard this record has already applied to AuthProvider configuration above, now applied to a layer with a more consequential blast radius: an AuthProvider misconfiguration narrows or widens what one credential can reach, while a deny policy or role deleted through this server changes what every principal it named can do until someone notices and reverts it.

This record also does not treat fine grained authorization and centralized audit logging, both stated in Google's own usage guide, as closing that gap. Fine grained authorization, on the evidence reviewed, governs which tool an identity may call at all, the same shape Organization Policy's own AuthProvider constraints already draw for configuration time enforcement rather than for the specific content of an individual call. Centralized audit logging, consistent with this record's own reading of Google's represented user attribution above, is evidence of what happened after the fact, not a control that determines, before a call executes, whether that specific call was inside the mandate anyone actually granted. Revocation and challenge authority for this specific surface are, on the same reading already applied throughout this record to Agent Identity and Auth Manager, unestablished: nothing reviewed here names a mechanism by which a human approver could hold or challenge a specific proposed create_deny_policy, delete_deny_policy or delete_role call before it executes, distinct from the IAM role gate that decides whether the caller may reach the tool at all.

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. CrowdStrike's own Agentic IdP, verified above, does not add a sixth architecture to this list in the sense of a new question; it is the same identity primitive versus credential broker split Google's own Agent Identity and Auth Manager already draw, reached independently by a security incumbent rather than a cloud platform, with its own action level authorization decision, Continuous Identity for AI Agents, and its own endpoint runtime enforcement, Falcon Guardian, both verified separately in Moona Intelligence's own Somansa Privacy-i AIDR record rather than here, for the same reason this record keeps Agent Gateway's own execution time check in its own place rather than folding it into Agent Identity.

Five 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, a cloud platform's own IAM identity and credential broker, and now a security incumbent's own agent directory and identity provider, keep landing on the same undocumented layer from five 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 and CrowdStrike's cases, which human or workload an audit trail can name alongside an agent's own registered identity. None of them, including this one, proves that the configuring party, or the human or workload an action is bound to, was organizationally entitled to grant or exercise what the configuration or the registration produced, or that a specific consequential action an agent took, using a credential or a token 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 and CrowdStrike have each made real, verifiable progress on the identity and credential layers of that chain, from two different starting points, a cloud IAM platform and a security incumbent's own agent directory. Neither has, on anything this record could verify, closed the gap underneath them: identity provenance is a prerequisite for trustworthy authorization, not a replacement for it.