platform_admin developer viewer execute

One identity model for everyone — and everything

People, AI agents, and applications, unified under one role-based access model. Authentication with SIWE, social login, account linking, single sign-on, machine identities, delegated agent authority, observability, cloud federation, and an offline edge tier — across every tenant.

Sign in, request your organization, verify your email — we’ll review and set you up.

Every way to sign in

Wallet-native and social login flows, all producing the same JWT identity.

Sign-In with Ethereum

EIP-4361 SIWE messages with nonce protection, domain binding, and automatic signature verification.

Social Login

Any OAuth2 provider with deterministic identity derivation. Users get a consistent identity regardless of how they sign in.

OAuth 2.0 + PKCE

Authorization code flow with S256 code challenge. Hosted sign-in page or bring your own frontend.

Standards OIDC Provider

Federate any OpenID Connect relying party — discovery, id_token, and userinfo over authorization-code + PKCE. No Guardius SDK required; your tenant is the OIDC client.

Account Linking

One identity, many credentials. Link a wallet to Google or Facebook (and unlink later) so a user is the same person however they sign in — a single identity_id across every login method.

Machine & Agent Auth

Agents and services authenticate with signed ES256K wallet assertions (RFC 7523 jwt-bearer), single-use to prevent replay, with an optional offline_access refresh pair for storage-less runs. No API keys — machine callers get the same JWT identity and permission model as people. And with a user’s consent, an agent can act on their behalf via RFC 8693 token exchange.

CLI Login

The guardius CLI — bundled with the TypeScript SDK — runs the same OAuth 2.0 + PKCE flow from your terminal: sign in with your wallet in the browser, get a token in your shell. login, token, whoami, logout — scriptable auth for ops and local tooling, no stored secrets.

One permission model for everyone

People, AI agents, and applications all share the same role-based access control. A single 6-part permission string governs every action in every tenant.

acts on behalf of Person user Agent agent App service Guardius RBAC evaluate & enforce region : platform : tenantId : resourceType : resourceId : action 6-part permission string — wildcards supported at every level platform_admin developer executor viewer

Groups & Roles

Assign roles to groups or individual identities. Flat groups collect users, agents, and apps. Role assignments bind to a specific tenant — add one role to a group, every member inherits the permissions.

6-Part Permissions

region:platform:tenantId:resourceType:resourceId:action with wildcards at every level. *:forge:acme-corp:documents:*:read lets an agent read all documents in a tenant.

Escalation Guard

Callers cannot grant permissions broader than what they hold. Every role assignment and permission delegation is validated against the caller’s own scope — privilege escalation is structurally impossible.

Mutable Roles

Eight default roles — platform_admin, tenant_admin, developer, viewer, executor, publisher, platform_ops, guardius_user — plus custom roles with CRUD APIs. Template variables expand to concrete grants per tenant and platform.

Provisioned Onboarding

New users get roles automatically at first sign-in — tenant default roles for open signup, or invite codes that confer tenant-bound roles. Grants land in the very first JWT, with no admin in the loop at signup.

Entitlements (app_metadata)

Attach server-authored, user-untrusted values to an identity — subscription tier, plan expiry, credit balance, cohort — delivered right in the access token. Roles answer “can they?”; app_metadata answers “how much / until when / which variant?”

Scenario: AI agent needs deploy access
// 1. Give the agent a "developer" role scoped to one tenant POST /rbac/identities/agent:deploy-bot/permissions { "roleTemplate": "developer", "platform": "forge", "tenantId": "acme-corp" } // 2. Agent tries to deploy — allowed POST /rbac/permissions/check { "identityId": "agent:deploy-bot", "permission": "*:forge:acme-corp:workflows:wf-42:execute" } // → { "allowed": true } // 3. Same agent tries to read billing — blocked POST /rbac/permissions/check { "identityId": "agent:deploy-bot", "permission": "*:forge:acme-corp:billing:*:read" } // → { "allowed": false }

Agents that act on your behalf — with your consent

An agent can act for a signed-in user without ever holding their credentials. The user grants standing, revocable consent; the agent exchanges the user’s token plus its own signed assertion for a short-lived delegated token; and every downstream system sees exactly who acted for whom. Scoped to a single platform — user, agent, and consent all live on the platform that issued the tokens.

RFC 8693 Token Exchange

Standards-based delegation at POST /auth/token: the agent presents the user’s access token and its own RFC 7523 assertion, and receives a delegated token. No custom grant, no shared credentials, no impersonation.

Verifiable Actor Chain

The delegated token keeps the user as sub and names the agent in an act claim. Resource servers always see both who authorized the action and who performed it — attribution is built into the token.

Per-User Consent

Delegation is opt-in per user, per agent. Grant it through the REST API, the SDK, or a hosted consent screen with a permission checklist — optionally limited to a subset and an expiry. Standing until revoked.

Intersection-Only Authority

A delegated token can never do more than user ∩ agent ∩ granted scope — evaluated live at every permission check, not frozen at issuance. When roles change, the token’s effective authority changes with them.

Instant Revocation

Revoke a consent and in-flight delegated tokens lose that authority at the very next check. A per-agent canDelegate kill-switch — off by default — cuts off a compromised agent across all of its users at once.

Fail-Closed by Design

Delegated tokens are short-lived with no refresh token, single-level (no re-delegation), and denied by default on Guardius admin and account endpoints — they are for your resource servers, nothing else.

Scenario: assistant places an order for a signed-in user
// 1. The user consents — "trader may act for me, orders only" POST /delegation/consents // as the user { "agentRef": "forge:acme:agent:trader", "scope": ["*:forge:acme:orders:*:read"] } // 2. The agent exchanges the user's token + its own assertion (RFC 8693) POST /auth/token { "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange", "subject_token": "<user access token>", "actor_token": "<agent assertion>", ... } // 3. The delegated token names both parties — user stays the subject { "sub": "<user>", "act": { "sub": "forge:acme:agent:trader" }, "permissions": [ /* user ∩ agent ∩ scope */ ] }

Isolated by default

Each platform gets its own namespace with independent configuration, credentials, and rate limits. Tenants within a platform provide further isolation.

Platform Lifecycle

Register, enable, and disable platforms. Disabling a platform immediately blocks all auth flows — token exchange, refresh, verify, authorize, and social login.

Scoped Tokens

JWTs include platform_id and tenant_id claims for downstream service authorization.

Self-Service Tenants

Create tenants via API with automatic tenant_admin role assignment. Configurable per-identity creation limits.

Origin Allowlists

Per-tenant redirect URI and CORS origin validation enforces OAuth security boundaries.

Branded Sign-In

Customize the hosted sign-in page per tenant — logo, accent color, theme, fonts, background, split-layout artwork — or set platform-level branding for tenant-agnostic flows.

Management Dashboard

A hosted admin console for platforms, tenants, roles, branding, onboarding, invites, and linked credentials — no scripting required to operate Guardius day to day.

Sign in once, across every tenant and app

A tenant-agnostic app doesn’t need to know the organization up front. Guardius authenticates the user, resolves which tenants they belong to, and returns a tenant-scoped token — reusing one hosted session across tenants and across every Penseur app.

Tenant-Agnostic Login

Redirect with just your platform_id — no tenant_id. Guardius signs the user in, finds their tenants on that platform, and auto-selects when there’s one or shows a hosted picker when there are several.

Hosted SSO Session

A secure, server-revocable session means users authenticate once and move between tenants — and between Penseur apps — without re-signing. Switching organizations is a fresh, tenant-scoped token, not a re-login.

App-Owned Non-Member Handoff

Members are gated by tenant-bound roles; signed-in users with no membership are sent to your own account-creation or request-access page (or a hosted fallback) — never a dead end.

From wallet to AWS — no static keys

The same identity that signs into your app can assume an AWS IAM role. An agent proves its wallet, gets a short-lived Guardius id_token, and exchanges it for temporary AWS credentials through standard web-identity federation — nothing long-lived to leak.

No static cloud keys

Agents and services never store an AWS access key. Their wallet signing key is the only secret; AWS credentials are minted on demand and expire in minutes.

Standard web identity

Exchange a Guardius id_token for temporary credentials via AWS AssumeRoleWithWebIdentity — vanilla IAM OIDC. No Cognito, no custom authorizers, no glue.

Scoped & audited

Each exchange assumes a least-privilege IAM role and lands in CloudTrail. Scope by agent (sub) or by a per-tenant audience — temporary credentials, never broad ones.

Auth at the edge — fully offline

Run a loopback sidecar that mints and verifies tokens on 127.0.0.1 with no hosted round-trip. Install the @penseurai/guardius-edge daemon, enroll once online — and manage your fleet from the dashboard; then machine identities and people authenticate, and admins run RBAC, entirely offline — on-prem, air-gapped, or partition-tolerant. Hosted stays the root of trust and the kill switch.

Offline Machine Identities

Agents and services mint and verify ES256 tokens locally against the edge’s own JWKS — no network, no latency, no hosted dependency on the hot path. Ideal for fleets running where connectivity is intermittent or absent.

Human Sign-In at the Edge

Real people sign in with their wallet via SIWE against the loopback daemon — wallet-only, fully offline — and receive edge-scoped tokens carrying their local roles. Same JWT identity model as the hosted service.

Full Local RBAC

Local admins author roles, assign them, grant ad-hoc permissions, and check access — all offline on the edge’s own store. Provision collaborators and revoke them without a hosted token.

Hosted Root of Trust & Kill Switch

Every edge enrolls against the hosted registry and syncs a signed projection. Revoke an edge — one click on the dashboard’s Edges page — and it self-halts on next sync. Central control survives even as tokens are issued locally.

Confined by Construction

Every local grant carries the edge’s own id in its tenant segment, so an edge admin’s authority can never exceed that edge — while the owner’s global wildcard still covers it. Isolation holds without a network check.

One SDK, Dual-Issuer Verify

Both SDKs — TypeScript and Python — verify hosted RS256 tokens and edge ES256 tokens, dispatched by issuer — fail-closed without the edge trust root configured. Consumers verify edge tokens with no code change.

Structured event tracking

Every authentication, permission check, and security event is captured with structured metadata for auditing and analytics.

Event Aggregation

Time-bucketed daily aggregates with sharded partition keys for high throughput. Query by event type, platform, or wallet address.

Security Event Priority

Security-critical events are preserved under load. Buffer overflow drops non-security events first, ensuring audit trails survive traffic spikes.

Structured JSON Logging

Every log line is a JSON object with timestamp, level, service tag, and structured data. Buffered writes for efficiency, immediate flush on errors.

RBAC Audit Trail

Permission grants, role assignments, group changes, and escalation denials are all emitted as events with full caller context.

Ready-made clients

Type-safe SDKs for TypeScript and Python at full feature parity — automatic token refresh, PKCE handling, full RBAC, delegation, and dual-issuer edge verification.

TypeScript — browser sign-in
import { AuthService } from '@penseurai/guardius-sdk'; const auth = new AuthService({ baseUrl: 'https://guardius.penseur.ai', platformId: 'my-app', tenantId: 'my-tenant', }); // 1. User clicks "Sign In" — connect wallet const user = await auth.signInWithWallet(window.ethereum); console.log(user.walletAddress); // 0x1234... // 2. Check what this user can do const canDeploy = await auth.hasPermission( '*:forge:acme-corp:workflows:*:execute' ); // 3. Tokens refresh automatically in the background auth.on('auth:refreshed', ({ user }) => updateUI(user));
Python — server-side verification
from guardius_sdk import AuthService, AuthServiceConfig auth = AuthService(AuthServiceConfig( base_url="https://guardius.penseur.ai", platform_id="my-app", tenant_id="my-tenant", )) await auth.initialize() # 1. Verify the token from an incoming request result = await auth.verify_token_with_server(token) if result.valid: print(result.claims["wallet_address"]) # 0x1234... # 2. Check permissions before allowing the action allowed = await auth.has_permission( "*:forge:acme-corp:documents:doc-1:read" ) if not allowed: raise PermissionError("Access denied")
TypeScript — act on behalf of a user (RFC 8693)
// 1. The user consents — once, standing, revocable await auth.grantDelegation({ agentRef: 'forge:acme:agent:trader', scope: ['*:forge:acme:orders:*:read'], }); // 2. The agent exchanges tokens — short-lived, no refresh const delegated = await agentAuth.delegateAs({ subjectToken: userAccessToken, privateKey: agentWalletKey, }); // 3. Downstream sees both parties // { sub: <user>, act: { sub: 'forge:acme:agent:trader' } }

JWT done right

RS256 asymmetric signing with automatic key rotation, refresh tokens, and a public JWKS endpoint.

RS256 / JWKS

Asymmetric JWT signing with a public /.well-known/jwks.json endpoint for zero-trust token verification.

Refresh Rotation

One-time-use refresh tokens with automatic rotation. Reuse detection immediately revokes the token family.

Auto-Refresh

SDK-level token lifecycle management. Access tokens refresh transparently before expiration.

Signed Cursors

HMAC-signed pagination cursors for tamper-proof, stateless pagination across all list endpoints.

Token Introspection

RFC 7662 /auth/introspect lets confidential clients validate and inspect a token server-side — active state, scope, subject, and claims — for backends that prefer an authoritative check over local verification.

Defense in depth

Multiple layers of protection against common attacks, from rate limiting to nonce replay prevention.

Rate Limiting

Per-IP sliding window with exponential backoff. Separate limits for auth, token exchange, and admin endpoints.

Nonce Protection

Cryptographic nonces with time-bound expiration prevent replay attacks on SIWE messages.

Subject Revocation

Revoke all refresh tokens for a user with a single timestamp marker. No need to scan or delete individual tokens — instant account-level lockout.

CORS Policy

Dynamic origin allowlist from configuration. Production guard rejects startup if no origins are configured.

Built for these architectures

Guardius shines when you need multiple identity types, tenant isolation, and fine-grained permissions in the same system.

AI Agent Fleet Management

Deploy autonomous agents across customer environments. Each customer is a tenant, each agent gets an agent: identity with permissions scoped to exactly what it needs. The escalation guard ensures no agent can grant itself broader access. Subject-level revocation instantly locks out a compromised agent across all tokens. When an agent must act for a specific person — place their order, file their deployment — RFC 8693 delegation issues a consented, short-lived token that names both parties. For on-prem or disconnected deployments, run the edge daemon so agents authenticate locally with no hosted round-trip.

agent:deploy-bot → *:platform:acme:deployments:*:execute

Disconnected & Air-Gapped Teams

A field crew, a sovereign on-prem install, or a time-boxed contractor needs auth where there is no reliable link to the hosted service. Enroll an edge daemon once, then people sign in with SIWE and admins author roles, assign them, and revoke — entirely offline. Hosted stays the root of trust: revoke the edge and it self-halts on its next sync.

enroll --admin 0xAlice → SIWE sign-in → local RBAC, offline

DAO Tooling Suite

Each DAO is a tenant. Members authenticate with their wallets via SIWE, and the same identity works across treasury management, proposal voting, and contributor payments. Social login provides an onramp for non-crypto contributors. A contributor who works for two DAOs gets separate scoped roles for each without conflicting permissions.

tenant_admin → multisig signers  |  developer → contributors

Internal Developer Platform

Each engineering team is a tenant managing shared infrastructure. Platform engineers hold platform_ops with broad read access. Teams get developer roles scoped to their resources — CI pipelines, secrets, deployments. CI/CD bots authenticate as agent identities. Self-service tenant creation lets new teams onboard without filing tickets.

groups → move engineers between teams by updating membership

Multi-Studio Gaming Backend

Each studio registers as a platform, each game title is a tenant. Players sign in with wallets for asset ownership or social login for mainstream access — both produce the same JWT identity. Game server bots are agent identities. Origin allowlists enforce that Studio A’s frontend can’t call Studio B’s endpoints.

platform:studio-a → tenant:battle-royale → agent:npc-engine

B2B API Marketplace

API providers register as platforms, enterprise customers are tenants. Each customer gets self-service tenant admin to manage their developers and API keys. The 6-part permission string maps cleanly to API resources. Scoped JWTs let downstream microservices enforce authorization without calling back to Guardius.

*:weather-api:acme-corp:endpoints:forecast:read