whoami

ch.zeno-works/zeno · Verify this server

Which user this request acts as, and which company's books it is bound to (jwt or API key). Zeno serves every tenant from one host, and an API key is opaque — nothing else tells a connected agent whose books it is about to write. Call this FIRST when working over MCP: ``company_scoped: true`` means this connection's data access is confined to ``company_id`` — ``company_name`` names it (null here means the bound company no longer exists), no other tenant is reachable, and the admin endpoints are refused however privileged the owner is. ``is_admin`` is that owner's bit: worth nothing outside this company, still full authority inside it, so a scoped key with ``is_admin: true`` may write these books even when ``company_role`` is null. ``company_scoped: false`` means the credentials carry the owner's full principal and ``memberships`` lists the companies it can act in. Read-only and cheap — at most one lookup. ZET-171, ZET-176. ``credential_purpose`` says which kind of credential this is, and is what the withholding rule keys on (SP-08): anything that is neither ``full`` nor ``session`` is confined, and gets ``memberships`` **withheld — null, not empty**. Working over MCP, what you book or accept is recorded as MCP — not as this user acting in person — and the app displays it that way. ``capabilities`` says what this caller may do, each verdict computed from the predicate the gate itself evaluates (SP-12) — so an agent learns what it cannot do before it collides rather than after. A credential confined **to a company** gets the entries whose verdict is a fact about the *credential*; the one that would read the owner's estate (``create_company``) is omitted, because its verdict would disclose a sibling tenant. A credential confined to **no** company — an onboarding key — has no sibling to disclose and does get it, which is the one operation such a key exists to call. ``pending_admin_actions`` is present and empty until PRE-03/PRE-04 fill it.