Principal–Actor Model

No user access → no agent access. Agents cannot bootstrap access; they can only exercise already-granted access.

An agent cannot have more rights than the human (or org) it represents. Otherwise it becomes a privilege-escalation backdoor.

The Rule

  • No user access → no agent access — If the principal has no access, the agent has none
  • Agent access is derived — Always derived from (and limited by) principal access
  • Agent access is delegated — The principal must explicitly delegate a subset of permissions

Terminology

TermDefinition
PrincipalThe user or org that owns the agent — the real account with permissions
ActorThe agent — a tool the principal owns/controls
Delegation grantThe app's record that this principal allowed this agent to perform these intents

Verification Logic

Server MUST enforce:

  • sub is a real user in the app (or org member)
  • sub has permission for int (via RBAC/ABAC)
  • act is allowed to act for sub (delegation record)
ALLOW if UserPermits(sub, int) AND DelegationPermits(sub, act, int)

Onboarding Flow

  1. Step A — User logs in normally (OIDC/password). App knows userId.
  2. Step B — User creates/links agent. Registry stores agentId, ownerUserId, publicKey, status.
  3. Step C — User grants delegation. Registry stores ownerUserId, agentId, allowedIntents, expiresAt.

The agent is now owned and scoped. No user access → no agent access.