What Onbe is, and what it is not

Onbe sits between the people in your organisation and the agents that act for them. An agent asks it for permission to do something on someone’s behalf; it answers with a token that is small, short-lived, and scoped to the intersection of what that person can do and what that agent is allowed to do. Every answer, including every refusal, is written to a ledger that cannot be quietly edited afterwards.

The problem it solves

An agent in production today usually holds a static API key. That key has three properties, and all three are bad:

• It does not expire. It worked on the first day and it will work on the thousandth. Rotating it means finding every place it was copied to, and nobody is sure how many places that is.
• It is not the caller’s authority. Whoever asks the agent to do something, the agent acts with the key’s permissions. Someone with read access asks it to summarise a ticket; the same agent could have closed the project, because the key could.
• It leaves the wrong name behind. Every line in the log names a service account. Which human was behind any given action is answered with timestamps and chat history, if it is answered at all.

Onbe replaces that key with an exchange. The agent presents the user’s token and its own signed assertion; it gets back a token whose subject is the user, whose actor is the agent, and whose scope is no wider than either of them.

What it is not

• It is not an identity provider. Onbe does not hold your users, their passwords or their group memberships. It trusts an upstream OIDC provider — Keycloak in v0.1 — to say who someone is, and takes that user’s access token as the subject of an exchange.
• It is not an API gateway. It does not sit in the request path between an agent and a tool. It issues tokens; the tool server validates them, with the SDK doing the work.
• It is not a policy engine for your business rules. Its policy is deliberately small: scopes, audiences, lifetimes, delegation depth. Whether a particular ticket may be closed is your application’s question, not Onbe’s.
• It is not an agent framework. It has no opinion about how your agent is built or which model it talks to.

What it expects you to run

Thing	Why	v0.1
An OIDC identity provider	To authenticate the human, and to answer whether they are still active	Keycloak
A database	The registry and the audit ledger	Postgres 16, or a file
Somewhere for each agent’s public keys	To verify the assertion an agent authenticates with	The control plane holds them

The control plane itself is one service and one database. Postgres for anything real; for a trial or a single node the embedded database is a file path and the same control plane above it. An agent’s public keys can sit in its registration, so the only thing you must run for an agent is the agent — it may publish its own key set over HTTPS instead, if you would rather.

It is its own OIDC issuer, so agents and tool servers discover it the usual way.

Where to go next

If you want it running, go to the quickstart. If you want to understand the shape of it first, delegation, not impersonation is the idea everything else follows from.