Identity model (uid/euid)

Status: Accepted

Identity model (uid/euid)

Decision

Every arpi worker session has two identity fields, modeled after Linux processes:

uid   = who spawned it     (the human, resolved from `arpi login` token)
euid  = what it runs as    (determined by IAM provider + definition)

• Permissions are determined by euid — what the IAM provider grants for that token and definition.
• Audit trail captures both uid and euid — who triggered it and what role it ran as.
• Revocation targets uid — revoke a user’s identity and all their derived sessions die.

This is sudo for developer environments:

sudo -u postgres psql            # uid=ale, euid=postgres
arpi spawn debug-prod --as root  # uid=ale, euid=root (if IAM provider allows)

What arpi does NOT own

• No profiles.yaml. Roles are defined by the IAM provider, not by arpi config files.
• No allowed_profiles.yaml. Access control lives in the IAM provider, not in a sudoers-style file in git.
• No agent-senior / agent-junior naming. Role names come from the IAM provider. arpi does not prescribe role taxonomy.
• No [iam] section in TOML definitions. IAM is runtime state (from the human’s token), not a definition property. The definition declares what secrets it needs; the IAM provider decides whether the current user can access them.

IAM is a core platform domain (see template-schema.md). The Identity domain owns authentication, role resolution, credential proxy, and the IAM provider interface. IAM code lives in the control plane, not in the CLI (which is a thin client).

How it works

1. Developer runs arpi login — authenticates with the IAM provider (currently Infisical), gets a token stored locally.
2. Developer runs arpi spawn <definition> — arpi resolves uid from the token.
3. The IAM provider determines euid (role) based on the token’s scope. Roles like root, developer, viewer come from the provider.
4. --as <role> requests explicit escalation — the IAM provider decides whether to grant it.
5. Both uid and euid are passed to the gateway and sandbox for audit and RBAC.
6. Agents get a default lesser token — lower privileges than the human who spawned them. Escalation requires explicit --as and provider approval.

uid resolution order

$ARPI_USER env var > IAM token identity > git config user.email > interactive prompt.

Verification

• arpi whoami shows uid and current euid from IAM token
• arpi spawn <def> --as root fails if the IAM provider does not grant the role
• Agents default to lesser token — not the human’s full privileges
• Audit log entries contain both uid and euid
• Revoking a uid in the IAM provider blocks all sessions for that user
• No profiles.yaml or allowed_profiles.yaml in the codebase