The identity fabric: who acts, whose keys, who pays

July 18, 2026

An AI agent working on your behalf rarely touches one system. It starts a runtime to run your code, calls a model gateway to think, reads and writes a data store, and drives a command-line tool that you also use from your own laptop. Four systems, one piece of work, and a question underneath every step: who is acting here, whose credentials are being spent, and who gets the bill?

Without a good answer, teams reach for the answer that always works in a demo and never works in production. They copy a key into the runtime. They paste another into the agent's config. They give the background task the same token the person uses, because it is the token that happens to work. Each copy is reasonable on its own. Added up, they are a pile of standing credentials scattered across four systems, and when something goes wrong there is no way to say which identity did it, or to take the authority back without hunting down every copy.

Picture the ordinary version of this. You ask an agent to run your test suite against last week's data, summarize the failures, and open a ticket. To do it, the agent needs a workspace to run in, a model to read the logs, the data itself, and a tool account to file the ticket. In the copied-key world, each of those four needs is met by a credential someone dropped somewhere: a provider key in the workspace, a database password in an environment variable, a personal token wide enough to file the ticket and also, incidentally, to delete the repository. If any one of those leaks, or if the agent is talked into misusing it, the damage is not scoped to the task. It is scoped to whatever the widest copied key happens to permit. And the bill, when it lands, says the workspace spent the money, which tells you nothing about who asked for the work.

The identity fabric is Latere's answer to that question, and it now runs underneath every product. This post is about what it does for you. If you want the design underneath it, the primitives and the contract they satisfy, that lives in Agent harness design: the identity fabric. Here we stay with the person using it.

The one guarantee

Everything an agent does is rooted in you.

The agent is a real identity. It has a name, a version, and its own record, which is what makes "the agent did this, not you" a sentence the system can say at all. But the agent is never a separate authority. It does not carry its own pile of permissions that outlive your say-so. When it acts, it acts as you, under a grant you gave and can withdraw. The runtime, the model gateway, and the data store all see the same owner behind the work, no matter which of them the agent is talking to at the moment.

That single rule has a partner: a credential minted by one product is only ever accepted back by that same product. The key that lets an agent reach models is good at the model gateway and nowhere else. The token that lets a workspace reach the network is good at that workspace's network boundary and nowhere else. One product's keys never become another product's keys, so a problem in one place stays in one place.

Those two sentences are the whole promise. Rooted in you, and sealed per product. Everything below is what they buy.

Go back to the test-suite task. The agent registers as its own identity and receives a grant that says, in effect, "act as this owner, for this scope, until revoked." When it starts a workspace, the workspace is created under you. When it calls a model, the call carries you as the payer and the agent as a label alongside. When the workspace reaches the network, it presents a token good only at that workspace's own boundary. Four systems, one owner behind all of them, and four separate short-lived credentials, none of which is a copy of a key you own. The agent is named on every line of the record. It holds authority on none of them.

What it buys you

Secrets never sit in plain sight inside a workspace. Your real keys stay in a private store that belongs to you. When a command needs one, the value is swapped in at the network boundary, at the moment the request leaves, and is gone before your own code runs. The workspace holds a placeholder, not the secret. So the blast radius of a leaked workspace is not "every key the agent ever used." The keys were never in the room.

A leaked workspace token can only do workspace things. The token a running workspace carries is scoped to that workspace's own network boundary. If it leaks, it does not unlock your model account, your data store, or your account settings. It unlocks the one narrow thing it was minted for. This is the difference between losing a house key and losing a key that opens only the mailbox.

Logging out, or revoking a grant, takes effect on the server, not just on your laptop. When you log the command-line tool out, the credential is revoked at the source, not merely deleted from your machine. When you withdraw an agent's grant, its runs stop being authorized. Access is something the platform can take back, not something you have to hope expires. (Already-running work holds its short-lived token until that token ages out; the design post covers why that window exists and why it is kept small.)

Spend is attributed to you and grouped by agent. Every model call and every unit of runtime carries a verified owner at the moment it happens, before the money is spent, not reconstructed afterward from three dashboards. Because the agent is a first-class identity riding alongside, you can also ask the narrower question: what did this agent spend? The bill rolls up to you; the breakdown separates by agent.

One login reaches the runtime and the model gateway, with no tokens to shuttle. You sign in once. From there the same identity flows to the workspace where code runs and to the gateway where models are called, and each hop mints its own short-lived, narrowly-scoped credential from that one login. You are not copying a token from one tool into another, and you are not issuing a long-lived key and praying it does not leak. The plumbing that used to be your problem is the fabric's problem.

None of this slows the agent down. It still runs at full speed. What changed is that the authority behind it stays with a person, and stays visible, instead of dissolving into a service account that nobody can point back to a decision.

Bring your own identity provider

If you run Latere against your own cloud, the fabric works against your own identity provider. A standard OIDC login through Okta, Entra, or Keycloak is enough. There is no Latere-specific feature your provider has to support, because the fabric was built to lean only on what every OIDC provider already does: authenticate a human.

The delegation, the scoping, the grant an agent runs under, none of that is asked of your provider. Your provider says who the human is; the product self-issues a scoped grant from that login and keeps it inside its own walls, revocable in the same place you manage every other token. The owner-rooted guarantee and the sealed-per-product guarantee both hold exactly as they do on the hosted side. You bring the login. The fabric supplies the rest.

What is still coming

Two pieces of the picture are built into the fabric but not yet wired end to end, and it is worth naming them plainly.

The first is data. Reaching your data store through a mounted drive, under the same one-login identity as the runtime and the model gateway, is specified and grounded in the fabric, but the workspace-side machinery that mounts and keeps a drive in sync is a feature still being built. Today the runtime and the model gateway are the two legs that carry your identity without a token to shuttle; the data-store leg lands when Drive mounts ship.

The second is cloud execution. When Wallfacer's cloud executors arrive, they join this same fabric rather than inventing a fifth way to hold credentials. The contract they will honor is written down; the executors themselves are the part still under construction.

Neither is a gap in the promise. The owner-rooted rule and the sealed-per-product rule already hold across the runtime, the model gateway, and the command-line tool that most people touch first. These two are the surfaces that adopt the same rules as they come online.

Where this leaves you

The thread through why Latere exists is that the most important intelligence in an autonomous system is the one you cannot see: the person who set the direction and drew the boundaries. Who an agent acts for, what it may reach, and how you take that authority back are among the most consequential of those boundaries, and they are exactly the ones a system erases when it drops a broad key into a config file and lets a trust decision be made once and never revisited.

The identity fabric keeps those decisions yours. The agent runs autonomously. The authority over who it speaks for, what it may touch, and what it spends stays with a person, which is the same bet the rest of Latere makes, applied to the ground every other product stands on.