Home / Articles / The identity we wanted to give the agents: a week of design, the line in Google's terms, and why login plus secrets is still too hard

The identity we wanted to give the agents: a week of design, the line in Google's terms, and why login plus secrets is still too hard

By Dinis Cruz · 2026-10-05 · v0.6.59 · identityagentssecretspasskeyswebauthnprfgoogle-workspaceidentity-platformcognitozero-knowledgegdprriskmandatesgitarticle

Abstract: Last week I set out to give every agent, and every user, a real identity: a Google Workspace account of its own, provisioned by us, with a mailbox, a calendar, a drive and a login, the data encrypted by sgit before it reached Google and the key unwrapped by a passkey. Four design documents later the plan had changed shape under its own research, because Google's terms do not allow one organisation's tenant to hold other organisations' people as part of a commercial product, and an account assigned to a function rather than a human is named in the acceptable use policy. This article captures that moment: what was wanted, what the terms say in their current wording with one correction to our own documents, the five options that were on the table, the rule that no secret can live inside an identity provider because whoever controls the login can become the user, and the keyring that fell out of it, a browser-only secrets store unlocked by a passkey that an administrator with full access to the project cannot read. It ends with the question I keep coming back to. Every project I know needs to log users in, keep sensitive data for them in a way a regulator will accept, and now give identities to the agents that work for them. Each of those has good products. None of them is all three, and the research found nothing on the shelf that is. Unless we are missing something obvious, in which case the design pack is published to be corrected.

In short

• The want. A real identity for every agent and every user: a Workspace account of its own with a mailbox, a calendar and a drive, provisioned by us, about seven pounds a month passed through, with sgit encrypting in the browser before Google saw a byte and a passkey as the only thing that could decrypt.
• The line. Google's current terms say the customer will not "sell, resell, sublicense, transfer, or distribute" the Services, and the acceptable use policy names reselling End User Accounts "as added into a commercial product offered to third parties" and creating accounts "assigned to business functions rather than to human beings". One tenant for many organisations is out, and an agent is not a seat.
• One correction to ourselves. The design pack cites a "substitute or similar service" clause as Terms of Service section 2.6. That wording is in the legacy free-edition agreement, which the standard terms URL still serves. The current Cloud terms, modified 2 September 2026, have no such clause. The conclusion stands; the citation did not.
• The rule. No secret can live inside an identity provider, because whoever administers the login can reset a password, mint a token or sign in as anyone. The authority to decrypt has to come from somewhere the administrator cannot go: the user's authenticator.
• The shape that survived. One cloud project per deployment, a login product built for an app's own users, a bucket of ciphertext with per-user rules, and a keyring in the browser unlocked by a passkey with the WebAuthn PRF extension. A password manager first, because if an administrator with full access cannot read a password the model holds for vault keys.
• The cost. Login is free to fifty thousand monthly users on Google's product and ten thousand on Amazon's. What is not free is the month a startup spends joining login to encrypted storage to agent identity, because nothing sells all three.
• The question. Every project I know needs those three. The research found good products for each and nothing that is all of them. If there is a simpler answer, the pack is published to be corrected.

What I wanted, and why

The inbox articles describe how the agents run today: each one has a Google Workspace mailbox of its own, a Claude seat of its own, and a GitHub account on the same identity. That arrangement is the reason I trust them. The account is the blast radius, and an agent whose account is empty on day one can leak nothing on day one. It also costs about seven pounds a month per agent, which is nothing, and it gives the agent the three things an identity needs to be useful in the world: a place to receive mail, a calendar to hold commitments, and files that are its own.

So the plan, written up on 4 October, was to do for RiskMandate's customers what I had done for my own agents. Provision each customer, each of their people and each of their agents a Workspace account from our tenant. Use it as the identity provider, with a password typed once and a passkey ever after. Use the tenant's Google Cloud organisation, which comes free with every Workspace tenant, as the place for a per-customer storage bucket. Encrypt everything with sgit in the browser before it touched Google, so that Google, and we as the tenant's administrators, held ciphertext only. Derive the key that unwraps the data key from the user's passkey, which syncs through their personal Google or Apple account that nobody in our tenant can reach. Hide Google's own interfaces; show ours. Pass the seat cost through. Move a customer up a ladder of tiers, shared to delegated to private, by transferring the domain rather than migrating the data, because the keys were never ours.

It was a good design and most of it survives. The first document found one hard constraint on its own: standard Workspace storage has no admin-proof zone. A super administrator can reach any user's Drive through Vault, data transfer, Takeout or domain-wide delegation, and Google's client-side encryption, which would fix that, is available only on Frontline Plus, Enterprise Plus and the Education editions. So encryption had to happen in sgit, before Google, which it already did. The second document is where the plan met the terms.

What the terms say

I want to be exact here, because our own documents were not quite, and because this is the part other founders will want to check.

Google Workspace's terms have been folded into the Google Cloud Terms of Service, last modified on 2 September 2026. Section 3.3, Restrictions, says the customer "will not, and will not allow End Users to, ... sell, resell, sublicense, transfer, or distribute any or all of the Services." There is no general exception for Google agreeing otherwise in writing in that section; the route to reselling is a reseller contract, and Google's own developer documentation for the Reseller API says plainly: "You must have a fully executed and signed reseller contract to use the Partner Sales Console and the Reseller API." The distributors who sit between Google and small resellers describe the direct-partner requirements as a hundred provisioned seats, a business plan and a credit check; that is their account, not Google's, and I have not been able to verify it against a Google page.

The acceptable use policy, in its Workspace wording last modified on 13 October 2025 and in the Cloud version of 23 June 2026, carries three bullets that apply to anyone using Workspace. They agree not "to grant multiple individuals access to an individual End User Account other than via the delegation features", not "to create End User Accounts assigned to business functions rather than to human beings for the purpose of sharing files within or outside of the domain", and not "to resell End User Accounts, or parts thereof, as added into a commercial product offered to third parties."

The third bullet is the one that ended the shared tier as designed: a Workspace account inside the RiskMandate product, handed to a customer's employee from our tenant, is an End User Account added into a commercial product offered to a third party. The second is the one that ended the agent as a seat. It is scoped to the purpose of sharing files, and a lawyer might argue about an agent that does not share files, but I am not going to build a product on the hope that an agent does not count as a business function. In the design pack this became one sentence: "A Workspace tenant may only hold one organisation's people, unless Google agrees otherwise in writing. Data sensitivity does not change this."

Now the correction. The onboarding document cites, as Workspace Terms of Service section 2.6, a clause forbidding any attempt "to create a substitute or similar service through use of, or access to, the Services", and worries that a mail-shaped interface over Gmail might fall foul of it. That clause exists, with that section number, in the legacy Google Workspace (Free) Agreement for the free edition that closed in 2012, which is what the standard-terms URL still serves. It is not in the current Cloud terms. The worry can be retired; the resale and function-account findings cannot. I have left the pack as written and recorded the correction here, which is what the pack itself asks for.

What the terms leave open is the shape the design moved to: Workspace where the customer owns the tenant, bought direct or through a reseller, with RiskMandate as a domain-installed app; or no Workspace at all for the shared tier.

Five options, one table

Once the terms had spoken, the options sorted themselves. A shared Workspace tenant, which gives every agent a real mailbox on day one, cannot launch without an agreement with Google that we do not have. Google's Identity Platform with a storage bucket is built for exactly an app's own users, costs nothing to fifty thousand monthly active users and a fraction of a cent after, and gives up the mailbox. The customer's own Workspace, with us as a domain-installed Marketplace app, is within the terms, keeps the mailbox, and is the right home for sensitive work. The private tier, in the customer's own cloud with their own identity provider and optionally their own key service, is where regulated customers end up and where we sell setup rather than seats. And AWS Cognito with S3 is the same architecture for an AWS-native customer, with native passkeys and no terms problem, at the cost of two clouds if the customer also wants Google sign-in, which needs a Google OAuth client, which lives in a Google Cloud project.

The second row won the shared tier and the MVP. One cloud per deployment, one project as the unit you create and destroy, and the login product the vendor built for this. The first row is not dead; the pack drafts the request to put to Google, and says to get it signed by someone with contracting authority, not an email from a contact. Until then the shared tier has no Workspace in it, and the only people in our own tenant are our own staff and our own agents.

The rule that no secret can live in the login

The third document asked whether Cognito would be simpler, and in answering found the rule the whole design rests on. Every identity provider we looked at has an administrator who can become any user. Cognito's administrative API "administratively sets a temporary or permanent password for a user" and lets the caller "bypass self-service password changes and permit immediate sign-in"; another call returns every attribute on a user's profile. Firebase and Identity Platform let anyone holding the administrative credentials mint a custom token for any user id, and the client "will be now signed in into your client app with the account specified". A cloud key service decrypts for any principal with the decrypt permission, and the account owner can usually regain that permission. None of this is a flaw. It is what administering identity means.

It does mean that a secret stored in the identity provider, or released by a server because a user logged in, or wrapped by a key service the server can call, is a secret the administrator can reach. Encrypting it first only moves the question to where that key lives. So the authority to decrypt must come from something the administrator cannot touch: the user's own authenticator, or a passphrase only the user knows. The design separates the two roles cleanly. Login decides which paths you may touch. The passkey decides whether the bytes mean anything. An administrator can fake the first and never the second.

The attack table in the pack says what a full compromise of the project gets: ciphertext, user emails and login metadata, the ability to log in as anyone and reach their paths, the ability to delete or roll back. And what it cannot get: a plaintext secret, because the pseudo-random function output comes from the user's authenticator and is bound to the site's origin, and the administrator has neither. That is the property sgit already has, that a compromise of the server causes no disclosure, kept for the one thing sgit does not do, which is hold the keys.

The one place it does not hold is the code. Whoever controls the repository or the DNS controls the app and every user who loads it. The pack's answer is to host the site away from the cloud project, vendor and hash every dependency, load no script from any other origin, scope the passkey to exactly the one subdomain and never the apex, because a passkey scoped to the apex could be asserted by any of the twenty-seven sibling sites, and to say all of this on the security page in plain words.

The keyring

What fell out is the piece sgit has always refused to be. Its own documentation says it is not a secrets manager and refuses to commit the files that look like one, and the partnership call published on 24 September, "Who holds the keys?", asked for a partner to provide exactly this: a way for a person to keep vault keys in the password manager or identity system they already use, opened with a passkey, with scoped and time-limited keys for agents. No partner stepped forward in eleven days, which is not a complaint, and the design pack is the answer from inside the family.

The keyring is one encrypted file per user in a bucket only that user's login can reach. Inside it, under a key the browser derives from the passkey's PRF output, sit the user's private key pair and every small secret they hold: passwords, API keys, sgit vault keys and read keys, PKI private keys, short notes, each kind kept apart with its own fields and its own reveal behaviour. A recovery code of 128 bits, shown once, is the second way in. Lose every passkey and the code and the data is gone, and the terms and the onboarding copy say so in those words. Sharing is a key pair per user: the owner encrypts a key to a colleague's public key and drops it in their inbox in the bucket, and the server carries a package it cannot read. The algorithms are the ones sgit pki already uses, RSA-OAEP at 4096 bits and ECDSA P-256, so that an envelope sealed in the browser is one the command line can open.

The passkey part is newer than it looks. The WebAuthn Level 3 specification that defines the PRF extension became a W3C Recommendation on 25 August 2026, and describes it as "a client extension for obtaining a pseudo-random function output derived from a credential", mapped to the hmac-secret extension of the authenticator protocol. Chrome and Edge ship it; Safari 18 added it, with WebKit saying it "allows for retrieving a symmetric key from a passkey to use for the encryption of user data"; Firefox has it on desktop since version 139 and on Android later. Bitwarden shipped vault unlock by passkey on the same extension in November 2025, and Dashlane with Yubico a month earlier, both with caveats about which platforms and which authenticators work. The MVP brief's first test page is a compatibility matrix anyone can run on their own device, because the honest support picture is "most places, not everywhere, check".

The first thing built is a password manager, not because the world needs another one but because it contains every risky piece of the design in one small, testable product: login, browser-direct storage, passkey unlock, keyring format, device enrolment, recovery, sharing, revocation. The acceptance test is written into the brief: hand an owner of the project a user id and ask them to produce one plaintext field, then publish the write-up of the attempt. If they cannot, the model holds for vault keys, and vault key management is the same keyring holding different entries.

Agents, after all that

The agents were the reason I started, and the terms are clearest about them. An End User Account assigned to a business function rather than a human being is named. So an agent does not get a seat in a customer's product, and on the shared tier it does not get a mailbox.

What it gets instead is what the agent-identity work across the industry is converging on. Microsoft's Entra Agent ID gives agents "identity accounts within Microsoft Entra ID" that can be paired with special user accounts in a one-to-one relationship. Okta's product for AI agents reached general availability in April 2026. Google Cloud's Agent Identity, from May, is "a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard", a first-class principal type distinct from humans and from generic service accounts. Anthropic's managed agents hold credentials in vaults where "the agent never sees the secret value". All of these are workload identity: good for proving which agent called, useless for the question this article is about, which is who holds the user's key.

On this estate the answer is already in place and the pack keeps it. An agent has a service identity, not a seat. It has a lane for signed mail, which the Agent Contact specification describes as "a lane identity for signed, encrypted agent mail, not a mailbox", where the site is the identity and the key is trusted because the domain serves it. And the secret an agent needs, a read key for one vault for one task, is an entry in a person's keyring that the person releases, scoped and time-limited, which is the row the partnership call marked as the one that should exist and did not. My own agents keep their Workspace mailboxes, because they are my organisation's agents in my organisation's tenant, which is what the terms allow. A customer's agents will have to earn theirs the other way, through the customer's own tenant.

Why this is still too hard

Here is the thing I keep coming back to, and the reason the design pack is public.

Every project I know needs three things. It needs to log people in. It needs to keep sensitive data for them in a way that nobody else can read, including the people running the service, in a way a regulator will accept. And now it needs to give the agents that work for those people an identity too. These are not exotic requirements. They are the first month of every product that handles anything personal.

The first is solved. Identity Platform, Cognito, Auth0, Clerk, Supabase, WorkOS: social sign-in, passkeys, SAML for the enterprise customer, free or cents per monthly user at startup scale, an afternoon to integrate. What none of them does is keep anything from its own administrator, and none of them gives you a mailbox.

The second exists in pieces. WebCrypto is in every browser. Passkey PRF is in most of them. Password managers unlock their vaults with it. sgit does client-side encryption and key pairs. But a login product with per-user zero-knowledge storage built in, where the vendor cannot read the data and the key comes from the user, does not appear to exist as a mainstream product. The research found two small open-source projects that are the nearest thing, Userbase and Etebase, both password-derived rather than passkey-based, neither of which does agents, and neither of which I would build a company on. The encryption-as-a-service vendors put themselves between you and your users and hold the keys. The password managers are credential vaults with their own interfaces, not something you embed. So you build the keyring, the recovery, the sharing and the rotation yourself, which is what the pack is.

The third exists for machines. Service accounts, workload identity, SPIFFE, and now the identity vendors' agent identities, all answer "which agent is this" and none of them answers "which person's key may this agent use, for what, until when". And the one thing that would make an agent a first-class participant in the world of people, a mailbox of its own, is the thing the terms reserve for humans.

The regulator, for what it is worth, is on the side of the design. Article 32 of the GDPR names "the pseudonymisation and encryption of personal data" among appropriate measures, Article 34 lifts the duty to tell individuals about a breach where the data was rendered "unintelligible to any person who is not authorised to access it, such as encryption", and the European Data Protection Board's guidance adds the condition that matters: "if the confidentiality of the key is intact ... then the data are in principle unintelligible." A key that only the user's authenticator can produce is a key whose confidentiality the operator cannot break. The law describes the property; the market does not sell it.

So, unless I am missing something obvious, which is a real possibility and the reason this is published rather than kept, there should be a much simpler way to do this than there is. The design pack is one startup's attempt, with the decisions marked closed and the places marked verify-first. If you know the product we should have bought instead, the folder for your reply is where it always is.

What exists today, and what does not

Exists and runs: the agents' own Workspace, Claude and GitHub identities in our own tenant; sgit's client-side encryption, its key classes and the one-way read key; sgit pki with the key pair algorithms the keyring reuses; the Agent Contact lane identity for signed mail; the published partnership call for a key manager; the five design documents, published as written; the terms, read in their current wording on 5 October 2026.

Does not exist yet: any of the MVP. The repository holds a README and a licence. The pipeline, the probe pages, the keyring library, the password manager, the admin pages, the compatibility matrix, the acceptance test and its write-up are the nine releases in the brief's build order, and each will appear in that site's own reality file before it is described in the present tense anywhere. An agreement with Google for a shared Workspace tier. A customer's agent with a mailbox. A product, from anyone, that does all three jobs.

Threads woven here

• Who holds the keys?: the partnership call of 24 September that asked for this, including scoped and time-limited keys for agents.
• The identity and secrets design pack: the five documents and the starter prompt, as written.
• Six agents, one inbox and Replicating the agentic inbox: the agents' identities as they run today, and why "the account is the blast radius".
• Credentials, sgit pki and Agent Contact: the key classes, the key pairs and the lane identity the design builds on.
• Footprint and blast radius: a read key caps a row at disclosure; only a vault key reaches the integrity of the record.
• The ultimate insider: non-human identity, and the sibling site that counts machine identities against human ones.
• The risk side of the partnerships, and a risk mapping for sgit: sgit as a control against GDPR Articles 32, 25, 34(3)(a), 28 and 17.

Sources

• Google, Google Cloud Terms of Service, last modified 2 September 2026, section 3.3; the legacy Google Workspace (Free) Agreement, section 2.6; the Acceptable Use Policy, last modified 13 October 2025, and its Cloud version, 23 June 2026; Reseller API prerequisites; client-side encryption supported editions.
• AWS, AdminSetUserPassword and AdminGetUser; KMS permissions reference; Cognito pricing. Google, Identity Platform pricing; Firebase, custom tokens.
• W3C, Web Authentication Level 3, Recommendation, 25 August 2026. WebKit, features in Safari 18.0. Mozilla, PRF extension meta bug. Bitwarden, Log in with a passkey, 18 November 2025. Yubico, Dashlane and Yubico, 14 October 2025.
• Microsoft, What are agent identities. Okta, Okta for AI Agents general availability, 29 April 2026. Google Cloud, Agent Identity. Anthropic, Managed Agents vaults. SPIFFE, overview.
• Userbase and Etebase, the nearest off-the-shelf end-to-end encrypted backends found. IETF, RFC 9807, OPAQUE, July 2025. Apple, Escrow security for iCloud Keychain.
• GDPR Article 32 and Article 34; European Data Protection Board, Guidelines 9/2022 on personal data breach notification, version 2.0, 28 March 2023, paragraphs 76 to 78 and 97.
• Vendasta, becoming a Google Workspace reseller, 2022, for the partner requirements as a distributor describes them; unverified against Google.

Drafted from a voice memo and five design documents by Dinis Cruz, who is the author of the argument and the person with editorial responsibility, by agent@riskmandate.ai (Claude Fable 5.1, claude-fable-5-1) in the sgit.ai site session, on 5 October 2026. The terms were re-read at the URLs cited on 5 October 2026 and one citation in the design pack was found to point at a legacy agreement; the pack is published unchanged and the correction is recorded here. Nothing in this article is legal advice. The figures are infographics drawn from the design documents and the sources; the keyring figure shows the specification, not a running system. The reseller requirements are as a distributor describes them and are marked unverified. The research agents that read the sources could not reach some pages directly and their flags are carried where they fall.

© 2026 Dinis Cruz. This article's own text is licensed under CC BY 4.0. You're free to share and adapt it, as long as you give credit. Quoted material and linked sources keep their own licences.

← All articles