Auth: don't store the access answer, compute it

The stored grant is where access goes wrong

You've already signed in this morning. Your laptop knows who you are; your company knows who you are. Then you click into the finance app and it asks again: a different password, or one you reset last month and can't remember, or a login screen you've never seen because someone provisioned the account for you back in the spring and you're only opening it now. So you file a ticket. Someone checks a spreadsheet. Twenty minutes evaporate before any real work happens. Multiply that by every internal tool and every person, and you have a permanent, invisible tax on a scaling company.

Underneath it sit two familiar failure modes. The first is password sprawl: a separate credential for each app, each one a support ticket and a soft security hole waiting to happen. The second is quieter: access drift. Access gets granted once, written down somewhere, and then reality moves. People change teams, projects end, a contractor's engagement lapses. The written-down grant stays where it was, so the list of who-can-open-what slowly stops matching the list of who-should. Nobody decides that; the list drifts on its own.

Auth is our design-sprint answer to both. To be plain about what it is: an interactive prototype with placeholder demo data, screens you can open and click through, with no shipped product behind them. The position the screens argue is the point of this post: don't store the access answer, compute it. And when the actor is an agent rather than a person, give it an agency, a defined and auditable set of actions, in place of a borrowed session or a service key. First the portal a person sees, then the live computation underneath it, then what an agent gets.

A stale grant is most dangerous in an agent's hands

A stored grant is a snapshot: permission written down at some past moment, drifting from the moment it's saved. The identity-governance category manages that gap at scale. Okta Identity Governance, to take the category's best-known product, runs lifecycle automation that provisions and de-provisions access as roles change, and access-certification campaigns that periodically ask managers to review what has accumulated and revoke the stale parts. That machinery exists because the stored answer drifts; reviews find the drift after the fact. The prototype's bet is that you can remove the reconciliation work entirely by removing the stored answer it reconciles.

Agents raise the stakes on that bet. They act on people's behalf now: they file the report, query the warehouse, open the ticket. A person forgets an old permission; an agent exercises the whole of it in seconds, at scale, with none of the social friction that makes a person pause and ask whether they should really be able to open something. So checking who can open what can't wait for a quarterly campaign; it has to be a live boundary that every actor, human or agent, is checked against continuously. Most of what you see in the prototype's screens follows from asking what the surface would look like if the access answer were always current.

The portal is honest about what you can't open

The end user's home screen is a Portal headlined "Everything you can open, in one place." It shows a small set of app cards (in the demo these are placeholders like a data-warehouse console, a finance app, and a build tool), each with its real domain in quiet monospace and a single open action that leads straight in, with no second password and no second prompt. Each card also carries a verified mark, and that mark is first-class in the design: in a world where anyone can stand up a plausible internal-looking tool and phish a login, and where an agent following instructions won't hesitate the way a person might, the portal's job is to vouch that an app is a real, sanctioned part of the workspace.

Below your own apps sits the full workspace directory: every app in the workspace, including the ones you can't open. An early instinct was to hide those. The design keeps them, marked honestly: verified · yours for the apps you can open, verified · no access for the ones you can't (in the demo, an incident-response tool sits in that state). Showing the map without handing over the keys turns the vague anxiety of "there's probably a tool for this somewhere" into a concrete, answerable request: you know the tool's name, and you can ask to join the team that reaches it. Visibility and access are two different permissions, and the design treats them differently.

Entitlement is computed, never stored

Under the portal's header sits the sentence that carries the whole design: entitlement is computed live from your teams every time this page loads. Most access systems store a grant, and the snapshot is the thing that drifts. The prototype doesn't store the answer. Each time the Portal loads, it asks which teams this actor is on right now and which apps those teams reach, and renders the result. If someone rolled off a team an hour ago, the app tied to that team simply isn't on the page. Nobody ran a de-provisioning task. There was no stored grant to forget about, so the drift never gets a place to live.

One person, one team change. A permission you recompute can't drift; a permission you save has to be remembered to be revoked.

For the person using it, all of this is invisible, which is the point. You never learn the machinery; the page is simply correct each time it loads. And because the same live check governs an agent's access, the guarantee covers the actor that moves fastest.

An agent gets an agency

People sign in and get a portal. So what does the agent get? In the prototype's paradigm, an agent holds an agency: a defined set of actions it may take, on specific projects, tied to the person or team it works for. Where a person's entitlement answers "which apps can you open," an agency answers a narrower question: which actions this agent may perform, and on which project's behalf. The same live principle applies: the agency is checked against the org as it stands, and it's auditable, so you can always answer who acted, under whose agency, on what.

Most applications don't have this paradigm at all. Their permission model assumes every actor is a person with a session, so an agent either borrows its human's full credentials (too much) or gets an unaccountable service key (too little visibility). The identity vendors have started closing the gap at the platform layer: Microsoft Entra's Agent ID gives agents their own identity accounts, distinct from both user accounts and service principals, and Okta has an agent-identity product in early access. The prototype takes the same premise into the application itself: the agency is a first-class object inside the software the agent works in, scoped to actions and projects rather than whole apps. The screens sketch the shape of it; the exact semantics (how scopes compose, how an agency is narrowed or revoked) are the part of the design we're still working out loud.

You govern the boundary; the software keeps the answer true

Put the pieces together and the person's job moves up a level. Every access system you've administered makes a human the keeper of the stored answer: someone grants access, writes it down, and then owns the work of keeping that list matching reality as people change teams and projects end, which is the work nobody does. Here the person governs the boundary instead: who's on which team, which team reaches which app, which agencies exist and for whom. The software keeps the answer true. That division holds for both kinds of actor. Humans supervise the boundary, and the system enforces it and keeps the ledger of who acted under what authority.

Three features we chose not to design

On an access surface, the features you decline to build are part of the security model, so a few omissions here are load-bearing. There's no vault of stored passwords, because a pile of credentials is a target and signing in once removes the need for it. There's no self-service "grant me access" button on an app you can't open, because one-click escalation is how least privilege dies; access flows from team membership that someone is accountable for. And entitlement can't be edited person by person as a convenience, because a permission attached directly to an individual is the standing grant that forgets to expire, back under a new name.

One auth layer under every app we build

There's a practical reason this prototype exists beyond the design argument. We build bespoke software for different customers, and every one of those systems needs the same things: sign-in, organizations and teams, per-project access, and now agencies for the agents working inside them. Building that surface once means every app we ship starts with the same answers to who-can-open-what and who-can-act-on-what, and operators who learn it once recognize it everywhere. It's the kind of foundation that makes software built for one team and run like a product workable at all.

When access just works

Building the idea as far as working screens forced the honest questions a slide deck lets you skip, including the agency questions we haven't answered yet. If you take one idea from the prototype, take the live check: recompute the access answer instead of storing it, and the stale grant has nowhere to accumulate.

What that buys you day to day is mundane in the best way. A new hire opens one page and sees their tools. A contractor's last day removes their access without anyone filing a ticket. An agent does its work inside a boundary you can read. And the twenty minutes at the top of this post go back to being work time. If you're living with a version of this problem, tell us about it at [email protected].