Open-source theAuth gives AI agents and humans scoped permissions, RBAC, SSO and SCIM

Two guides published on dev.to on October 10 walk through theAuth, an open-source TypeScript authentication library (@glinr/theauth) that treats AI agents and human users as distinct identities with narrowly scoped permissions. One post covers per-agent identity and authorization; the other covers the multi-tenant side of the library: organizations, role-based access control, single sign-on and SCIM provisioning. The posts belong to an eight-guide series, and the author discloses having written parts of the library, so the material reads as maintainer documentation rather than a neutral review.

The shared-key problem

The agent guide opens with a familiar failure mode: a single human API key copied into a cron job, a Slack bot, a code-review agent and a forgotten notebook. According to the dev.to post, that arrangement fails in three compounding ways. A code reviewer that only needs to read pull requests inherits the human's write access everywhere; rotating the key breaks every consumer at once while an exposed credential stays live; and the audit log names the human on every row, making it impossible to tell which process actually performed an action.

Agents get their own identities

theAuth's answer is to give each agent its own database row, owner and permission list. An agent is explicitly not a user: it has no email, password, session or OAuth account, just a bearer token and a permission set. Tokens are prefixed kv_, run 46 characters and encode 32 random bytes; only a SHA-256 hash is stored, so a full database dump cannot reveal a live credential. The plaintext appears exactly once, at creation, and must be saved to a secrets manager immediately or rotated.

Agents come in three types: autonomous for unattended jobs like cron tasks (the default), delegated for short-lived workers that inherit narrower permissions through a delegation chain, and service for long-lived infrastructure identities such as MCP servers. Enforcement happens through an authorize() call that application code must place in front of every sensitive action; it returns allow or deny with an audit ID and supports constraints such as rate limits, argument patterns and time windows. HTTP middleware maps invalid tokens and missing permissions to 401 and 403 responses. Defaults lean conservative: every decision is logged, new agents expire after 24 hours unless configured otherwise, and each user is capped at ten active agents. The library targets Node 20 or newer, with SQLite in the guides' examples and Postgres supported for production.

Orgs, RBAC, SSO and SCIM

The second guide targets the moment an enterprise buyer asks for Okta login and automatic deprovisioning. It layers five pieces: an organization module for tenancy, built-in and custom roles for RBAC, a relationship-based engine for per-resource decisions, an SSO module handling SAML 2.0 or OIDC routed by email domain, and a SCIM plugin that provisions and deactivates users from the identity provider.

Four roles ship built in — owner, admin, member and viewer — and organizations can define custom ones with arbitrary permission strings such as invoices:pay. Runtime checks are a single hasPermission call, and an optional plugin registers organization routes that require an authenticated user. Defaults include 100 members per organization, five organizations per user, seven-day invitation expiry and an hourly invitation cap of 50. The ReBAC engine registers resources in a tree and adds relationship tuples to answer questions RBAC cannot, such as whether a specific user can open one document because they edit its workspace.

Rough edges the guides admit

The posts are candid about limits. Exceeding the per-user agent cap throws a plain error with no dedicated code, and the REST endpoint surfaces it as a 500. The separate tenant module is a data model, not an enforcement layer: authorize() does not compare tenants and suspending one blocks nothing, so the author treats tenantId as a label to check manually. A broader handleRequest route table performs no authentication at all and must sit behind custom checks. Most fundamentally, theAuth is a decision point, not a sandbox — if an agent can reach a database directly with its own credentials, no permission list stops it.

Why it matters

Agentic workloads multiply credentials faster than most teams can govern them, and borrowed human keys make both audits and revocation meaningless. Putting agent identities, hashed short-lived tokens and enterprise human auth — SSO, SCIM, RBAC — into one open-source library collapses work that teams often hand-roll over weeks into configuration. The enforcement gaps are real and acknowledged, but per-agent scoping with default expiry attacks the two worst properties of shared keys: unbounded blast radius and stale secrets that never expire.