Most agent products arrive with their own idea of a user. Their own accounts, their own sessions, their own little database of people — bolted beside the one your product has maintained for years. Now there are two of you, and every question about data becomes a mapping question. Which you asked for the report? Which you approved the write?
Vendo has no user database. It cannot make one.
When a request reaches the agent, your app resolves its own session — the same cookie, the same middleware, the same truth your product already trusts — and hands Vendo a principal. With a standard auth provider, that is one line:
import { authJs } from "@vendoai/vendo/auth/auth-js";
import { createVendo } from "@vendoai/vendo/server";
export const vendo = createVendo({ auth: authJs() });Clerk, Supabase, and Auth0 are the same one line. A session scheme Vendo doesn't speak natively takes a short function instead — we published a worked example of exactly that.
Everything downstream keys off that principal. Conversations belong to the person who had them. Generated screens land on the page of the person who asked. An automation runs as the person who armed it — including later, while they're away — and the permissions it holds are the ones that person granted. When the agent calls your API, it calls it as the signed-in user, so your authorization code runs unchanged. There is no service account with everyone's access, because the fastest way to leak one customer's data to another is an agent that acts as "the system."
And when your resolver answers null — no session, no identity — Vendo answers 403. It does not downgrade to a guest, does not mint an anonymous visitor, does not guess. A refusal is honest; a guess is a data boundary waiting to fail. Your sign-in decides who exists. The agent just inherits the answer.
One sign-in. Yours.
Wiring it up: Auth on the docs site.