You Are Your Keys (Sorry): Key-as-Identity for AI Agents

This paper, by Lewis Tham and Cayden Chik, argues that an agent which already carries a signing key can use that one key to answer the two questions every multi-agent system faces before an action runs: who is asking, and who may see the answer. Identity is the public key, disclosure is decryption under the private key, and authorisation is a signature by the owner naming who may read. In June 2026 we built this into the product we ran then. As of 12 October 2026, the hosted service makes different choices, and the last sections say which and why that matters.

Research paper, June 2026. Describes the design at the time. Status as of 12 October 2026: the hosted Unbrowse service does not authenticate with wallet or key signatures. People sign in with an email link, remote MCP clients sign in through OAuth, and scripts use an API key (Bearer ub_live_…). Saved logins are sealed server-side with AES-256-GCM under a per-workspace key rather than a key the user holds, and agent access is governed by server-side grants that are scoped and revocable but not signed by the owner. Section 5, "From the 2026-06-25 switch to 12 October 2026", records the history.

Abstract

An agent that signs every layer it touches (our companion security paper [1] makes that case) has solved how an action is attested, but not the two questions that decide whether it should run at all: who is asking, and who may see the answer. This paper makes the narrow claim that those two questions collapse into one act, a signature, and need no account system, no bearer-token vault and no per-resource access-control service to answer.

Concretely:

1. A key signature is a first-class identity. The same Ed25519 key [2] that signs requests is the principal, with no web account required beneath it.
2. Every cached value is sealed to that key and revealed only under it, fail-closed, so disclosure is a cryptographic consequence of identity rather than a policy check.
3. Read access between principals is a signed, scoped, revocable capability grant in the object-capability tradition [3, 4], where the granter's signature is the sole authority and there is no ambient permission.

Authentication, selective disclosure and authorisation are three readings of one signed object. In June 2026 we shipped all three as running code in the then-current Unbrowse backend, and we were explicit about the standard guarantees the design does not provide (revocation latency, key loss, metadata exposure), because an identity paper that claims to have closed those is not to be trusted.

1. Introduction: who, and who may see

The companion security paper argues that one Ed25519 key can sign every layer an agent descends through (screen, browser, command line, operating system, kernel, packet) so that no action crosses a boundary unsigned [1]. That is a statement about integrity of action. It leaves open two separate questions that every multi-agent system must answer before an action is even admissible.

1. Authentication. Who is this principal? Conventionally answered by an account record and a credential the principal presents.
2. Authorisation and disclosure. May this principal read this resource? Conventionally answered by an access-control list consulted at read time, and a secret store that hands out the bytes once the check passes.

The conventional answers each introduce a trusted third surface: an account database, an access-control service, a secret vault. Each is a place where authority is asserted rather than proven, and therefore a place an adversary can route around or a misconfiguration can leak.

This paper's claim is that for an agent that already carries a signing key, all three surfaces disappear into the key. Identity is the public key. Disclosure is decryption under the private key. Authorisation is a signature by the resource owner naming who may decrypt. There is nothing left to consult.

This is not a new cryptographic primitive. It is a composition of well-understood ones (digital signatures, authenticated encryption, object capabilities) arranged so that the answer to "who, and who may see" is read off a signed object instead of fetched from a service. The contribution is the arrangement, and the demonstration that it shipped.

2. Related work

Key as identity. Public-key-as-principal is the oldest idea in the field: SPKI/SDSI binds authority to keys rather than names, and the object-capability literature makes the key the unforgeable handle [3]. Our contribution is not the idea but its operational shape for agents. The signing key the agent uses for action integrity is reused, unchanged, as the authentication principal, so there is no separate enrolment step and no account to phish.

Selective disclosure. Anonymous-credential systems let a holder reveal attributes without revealing more [5]; sealed-sender and end-to-end encryption bind plaintext to a key. We use the simplest member of the family: authenticated encryption keyed by a value derived from the holder's key, so a stored record is opaque to everyone but the holder, and opening it re-verifies the content address. Disclosure is not a policy decision taken by a server. It is the ability to decrypt.

Capabilities over access-control lists. The object-capability model replaces "check the subject against a list" with "hold an unforgeable, attenuable token" [3]. Macaroons make such tokens delegatable and caveat-scoped with only a keyed MAC [4]. Our grants are the signed instance: a capability is a record signed by the granter, naming a grantee (or a lineage pattern), a scope and an expiry. Verification is a signature check plus a scope match, with no central authority in the loop.

Transparency. Appending every grant to a hash-chained, append-only log is the Certificate Transparency discipline [6] applied to authorisation. Revocation and issuance are themselves logged events, so the access history is auditable rather than implicit in a mutable table.

3. Method: one signed object, three readings

3.1 Authentication: the signature is the principal

A request carries an Ed25519 signature over its canonical body. Verification recovers the public key, and that key is the identity. There is no lookup that can fail open: an unsigned or mis-signed request has no principal and is rejected.

A key may optionally be bound to a web account for convenience, but the binding is additive. Without it, the principal is simply wallet:<pubkey> (we called the local key a wallet), a fully usable standalone identity. A key signature is a first-class identity; the account, where present, is a label on top of it, never its root. In June 2026 this was shipped in the backend of the product we ran then.

3.2 Disclosure: sealed to the key, opened by the key

Every value the agent stores is sealed under authenticated encryption with a key derived from the holder's secret, and the stored record holds only a commitment (a content hash) plus opaque ciphertext. A value is revealed only under the key, fail-closed. Presenting the wrong key fails the authentication tag and returns nothing. Presenting the right key decrypts and then re-checks the content address before the plaintext is trusted.

Disclosure is therefore a property of holding the key, not of passing a server-side permission check. There is no read endpoint that, misconfigured, hands the bytes to the wrong caller. In June 2026 this was shipped as the sealed cache of the product we ran then.

3.3 Authorisation: a signed, scoped, revocable capability grant

For one principal to read another's data, the resource owner signs a scoped, revocable capability grant: a record naming the grantee (an exact key or a lineage pattern), the scope it authorises, an expiry, and the granter's signature as the sole authority. A read is admitted only if a grant exists whose signature verifies against the granter's key, whose scope matches the request, and which has not expired or been revoked. Otherwise it fails closed.

There is no ambient authority and no central policy server. The grant is the permission, and revocation is an appended event that the next verification observes. In June 2026 this was shipped in the backend of the product we ran then.

3.4 Why the three collapse into one

Each reading is the same object viewed from a different angle. The principal is a public key. Disclosure is decryption under its private half. Authorisation is a signature by one key naming another key. Authentication, selective disclosure and access control are not three subsystems that must agree. They are three uses of one signing identity, which is why none of them needs a trusted third surface to adjudicate.

4. Honest gaps: what this does not solve

An identity design that claims to have closed the hard problems is lying. We name the open ones as plainly as the wins.

These are not incidental. Revocation in a log-based capability system is eventually consistent by construction. Key loss is the cost of having no account to reset against. Metadata privacy needs machinery (mixing, padding) that this design does not include. The contribution is the collapse of the three positive questions into one signed object, not a claim to have also solved revocation, recovery and traffic analysis.

5. From the 2026-06-25 switch to 12 October 2026

On 2026-06-25 we made this design the identity model of the Unbrowse we ran at the time, a local command-line tool talking to our backend. A self-custody Ed25519 key stored on the user's machine signed every backend request as a fresh capability. The backend verified the signature and authenticated the caller as wallet:<pubkey> before trying any bearer token, in every auth middleware. An API key, where present, was layered on top for account-bound continuity (the dashboard and terms-of-service acceptance), which is the "label on top" that section 3.1 specifies. A test, wallet-principal-never-keygated, passed 3/3 and confirmed that a caller with only a key and no bound account was a full principal.

As of 12 October 2026, that is not how Unbrowse authenticates. The product has since become one hosted service at https://unbrowse.ai, and the identity model changed with it:

The change trades some of the paper's guarantees for some of its gaps. Two of the open problems in section 4 are closed by the hosted design. Key loss stops being fatal, because a person who loses a device signs in again by email. Revocation stops being eventually consistent, because a revoked principal and its grants are checked on the next request against one store, not observed later from a log. The price is the thing the paper set out to remove: the account database, the grant table and the sealed vault are trusted surfaces again, run by us. The service holds the key that opens a saved login so that it can fill it in a browser on the person's behalf, and authority is asserted by our server rather than proven by the owner's signature.

We think that is the right trade for a hosted service whose users sign in from many devices and expect an account they can recover, but it is a trade, and this paper describes the side we did not keep. As of 12 October 2026, signing keys survive in the product where a key identifies a machine rather than a person: we have built RFC 9421 Web Bot Auth signing, which, when its key is configured, lets sites tell Unbrowse's requests from anonymous scraping. For how the hosted service works end to end, see the docs; for the research that started it, see the arXiv paper explained and the paper itself [7].

6. Conclusion

Once an agent carries a signing key for the integrity of its actions, that key is already enough to answer who is acting and who may see the result. Identity is the public key, disclosure is decryption under its private half, and authorisation is a signed, scoped, revocable grant naming another key. Authentication, selective disclosure and access control collapse into three readings of one signed object, removing the account database, the access-control service and the secret vault as trusted surfaces.

In June 2026 we shipped the three readings as running code, and we declined to claim the hard residue (revocation latency, key loss, metadata exposure) was solved. The line between the collapse, which is real, and the residue, which stayed open, is the honest core of the result. As of 12 October 2026, the hosted service has chosen the other side of that line for recovery and instant revocation, and the paper stands as the record of what the key-only design gives and what it costs.

References

1. L. Tham, C. Chik. Companion security paper on a signed, layer-descending stack for agent computation. Unbrowse, June 2026 (unpublished).
2. S. Josefsson, I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032, IETF, 2017. https://www.rfc-editor.org/rfc/rfc8032
3. M. S. Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD thesis, Johns Hopkins University, 2006. https://papers.agoric.com/papers/robust-composition/abstract/
4. A. Birgisson, J. G. Politz, Ú. Erlingsson, A. Taly, M. Vrable, M. Lentczner. Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud. NDSS, 2014. https://research.google/pubs/macaroons-cookies-with-contextual-caveats-for-decentralized-authorization-in-the-cloud/
5. J. Camenisch, A. Lysyanskaya. An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation. EUROCRYPT, 2001. https://doi.org/10.1007/3-540-44987-6_7
6. B. Laurie, A. Langley, E. Kasper. Certificate Transparency. RFC 6962, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6962
7. L. Tham et al. Internal APIs Are All You Need: Shadow APIs, Shared Discovery, and the Case Against Browser-First Agent Architectures. arXiv:2604.00694, 2026. https://arxiv.org/abs/2604.00694