Skip to main content
Authorization controls which operations a caller can perform. Per-user data isolation controls which rows a caller can see and write. Opt in with user_isolation=True:
When enabled, AgentOS uses the JWT sub claim as the user_id for every non-admin caller: A caller holding admin_scope (default agent_os:admin) bypasses isolation and sees all data. Set a custom override with admin_scope="ops:admin".
Isolation is off by default. JWT and scope checks still apply when user_isolation=False, but routes operate on the unscoped database and add no per-user ownership gates on top of authorization. Per-user isolation requires a database that records user_id (PostgreSQL recommended for production).

Service Accounts

Service account principals (sa:<name>) are always scoped to themselves, regardless of the user_isolation flag. The scoping decision runs in this order:
  1. A caller holding the admin scope is never scoped. This is checked first, so an admin service account reads across users.
  2. A service account is scoped to its own sa:<name> principal, even when user_isolation=False.
  3. JWT callers are scoped to their sub only when user_isolation=True.
A machine token stamps its sessions and memories with its own principal, so an unscoped default would read every user’s history. If you need a token that reads across users, mint one with the admin scope.

Next Steps