AGENT OS · TRUST BOUNDARY
Identity, isolation, and audit — built in
Four-tier hierarchy. JWT + OAuth 2.0. MFA. Per-step credential isolation that makes embeddable AI safe.
Auth Manager is the trust boundary of Agent OS. It models identity as four nested entities — Administrator, Organization, Application, User — and issues RS256-signed JWTs scoped to each. Together with the Orchestrator's per-step credential isolation, this is what lets one AI run safely across many tenants in the same product.
4
Identity tiers
RS256
Signed JWTs
100%
Audit coverage
Four-tier identity
Every token names the tier it represents. Permissions never escalate by accident.
Why most AI integrations leak credentials
Three failure modes that quietly turn an AI feature into a security incident.
One token, many sub-agents
Spawning specialists with the same access token means a prompt injection in one can act with the privileges of all.
No audit trail per agent action
Who triggered which side-effect from which step? Without a structured audit log, you cannot answer that question post-incident.
Building auth eats the roadmap
OAuth, JWKS, MFA, rotation, refresh, audit — building these properly is months of work that has nothing to do with your product.
What Auth Manager does
Four guarantees that make multi-tenant AI safe by default.
▤
Four-tier hierarchy
Administrator → Organization → Application → User. Each tier has its own ID format, its own login model, and its own permission scope. No accidental cross-tier escalation.
♣
RS256 JWT + OAuth 2.0 client credentials
JWKS-published verification. Public-key rotation with 24-hour overlap. Other Agent OS services verify without phoning home.
⊟
Per-step credential isolation
When the Orchestrator hands a step to a specialist, Auth Manager mints a narrow token scoped to that step's needs. Compromise one step — lose only that step's scope.
✎
MFA, rate-limiting, full audit logs
TOTP MFA for administrators. Per-token rate limits. Every issuance, refresh, revocation, and permission change is logged for compliance review.
Three token types, one signing key
What each token can do, and when it carries an org claim.
| Type | Purpose | Carries org claim |
|---|---|---|
admin | Admin management operations | No |
app | M2M API access (client credentials) | Yes — org name |
user | End-user authentication | Yes — org name |
Auth Manager, honestly compared
What you get on day one vs. the alternatives.
| Capability | Interactor Auth | ChatGPT / Cowork | Build from scratch |
|---|---|---|---|
| Multi-tenant identity | Yes — 4 tiers | Single-tenant | Yes — 3+ months |
| Per-step credential isolation | Yes — narrow tokens | Shared token | 3+ months |
| MFA + rotation built in | TOTP, 24h overlap | Auth via provider | 2+ months |
| Audit log per token action | Yes | Limited | Yes — careful |
| Time to safe multi-tenant launch | Days | N/A | 6+ months |
Bring your trust model. We'll map it.
Walk us through how your customers, sub-orgs, and services authenticate today. We'll show how Auth Manager fits — and what you stop maintaining.