Access is provisioned, not requested

• Your organization is onboarded. The boundaries, the connections and the people who may administer them are configured as part of that.
• You are named. Administrative access is a role assignment held by an identified person, not a shared login.
• You authenticate at your own identity provider. AAG trusts two identity issuers — Google, and Microsoft Entra — and trusting one is an explicit decision rather than a default. Two issuers is not two issuer strings: Google is recognised as either of two exact spellings of itself, while Entra mints a value scoped to each tenant and is recognised by shape rather than from a list, so no allowlist of tenants narrows it. Only the Google path is built. A token minted by the other is refused today, and the refusal distinguishes an issuer AAG has not decided to trust from one it trusts and has not finished: the key-fetching path Entra needs does not exist on this estate yet, and the tenant policy behind it is an unmade decision. So an organization whose people hold only Microsoft work accounts cannot reach AAG through them today, whatever else this site says about being onboarded. A person proves who they are to their own organization’s identity provider, which hands AAG a signed token rather than a password; AAG never receives one and so has none to keep. An identity is keyed by issuer and subject together — a bare subject is not an identity, and an email address is never used as the key, so the same address at two issuers is two identities and cannot be confused for one.
• Your sign-in address is issued to you. It is not published here, and possession of a link is not authorization on its own.

AAG is early, and the honest version of this page says so. The administrative surfaces described in the product model are being built; access today is granted through direct onboarding rather than through a public application. The security overview sets out what exists, what does not, and what has not been independently verified.