{"slug": "soulauth-rust-identity-infrastructure-for-humans-and-ai-agents", "title": "SoulAuth – Rust identity infrastructure for humans and AI agents", "summary": "TRANTOR LABS, Singapore, released SoulAuth, an open-source identity and authentication infrastructure written in Rust that treats both humans and AI agents as first-class 'Actor' subjects, supporting self-hosting and OpenID Connect. The system, which integrates with SoulseedOS, aims to establish a stable identity root for AI actors before memory, knowledge, and action, distinguishing Actor Identity from accounts, credentials, and clients. SoulAuth is part of TRANTOR LABS' broader AGI infrastructure, which includes SoulseedAGI as the mind kernel and SoulseedOS as the runtime and governance operating system.", "body_md": "**Actor-native identity infrastructure for Human and AIActor subjects.**\n\nSoulAuth is open-source identity and authentication infrastructure built by\n**TRANTOR LABS, Singapore**. It is written in Rust, supports self-hosting and OpenID\nConnect, can serve Web, Backend, API and AI / Agent systems on its own, and integrates\nnatively with SoulseedOS.\n\n中文版本见\n\n[README.zh-CN.md]。 Full documentation:[https://soulauth.trantorlabs.sg/]\n\nTraditional identity systems assume the subject is a Human User; a bot, service account or agent is a special object hanging off a human account or an application. As AI moves from a one-shot call towards an Actor that keeps understanding, judging, calling tools and taking part in real-world action, a more basic question surfaces:\n\nWho is being authenticated?\n\nSoulAuth starts from that question and puts **Actor Identity** at the centre of the\nidentity model. Human and AIActor can both be first-class subjects; they may hold\ndifferent credentials, authentication methods and lifecycles, but they enter the same\nActor-native identity contract.\n\nFirst-class standing for Human and AIActor does not mean the two share credentials, capabilities, lifecycles, permissions or legal status. It means each can independently be a subject that is identifiable, authenticable, able to establish an AuthSession, able to be expressed through a token, and attributable in the audit trail.\n\n**Actor Identity is the identity root; a credential is how a subject proves itself.**\nA human can use a password, MFA or an external identity; an AIActor uses a key-based\ncredential suited to a machine subject. The paths converge on one authentication core\nand produce a standardised authenticated identity and claims.\n\nSoulAuth proves who an Actor is. It does not grant that Actor any power to act just because authentication succeeded. In a Soulseed environment the AIActor itself is defined by SoulseedAGI; SoulAuth authenticates that subject through a controlled Canonical Actor Binding, and never defines, modifies or owns its Mind.\n\nLarge language models already provide increasingly strong generation, understanding, reasoning and tool use. We prefer to read an LLM as the general compute of the intelligence era, something like a CPU: it supplies intelligence, but it does not by itself produce the identity, continuity, accountability and governance order that a long-lived intelligent system needs.\n\nOnce AI stops being a single call and becomes a continuously existing Actor, the system has to answer, reliably: who is understanding, who is judging, who is acting, and to whom the result belongs.\n\nThat is why SoulAuth is **Actor First**. Before memory, knowledge, judgment, action and\naccountability, establish a stable *who*.\n\nSo SoulAuth does not keep the traditional `User`\n\nas the root of every identity object,\nand it is not a `type = ai`\n\ncolumn added to a user table. A few boundaries hold\nthroughout:\n\n```\nActor Identity ≠ Account\nActor Identity ≠ Credential\nActor Identity ≠ Client\n\nAuthentication ≠ Authority\n```\n\nHuman Account, Identity Binding, Credential and Client each have their own responsibility, and none of them can stand in for Actor Identity.\n\nSoulAuth runs on its own, but it is not an isolated thought project. It is also part of TRANTOR LABS' answer to the question of AGI infrastructure.\n\nOur reading is this: if the LLM supplies the intelligence, a system built for long-lived AIActors still needs a Mind above it, continuous operation, governance, applications, and the order required to enter public reality.\n\nThe infrastructure divides into four layers of responsibility.\n\n**SoulseedAGI — the mind kernel** defines the AIActor and its continuous Mind.\n\n**SoulseedOS — the runtime and governance operating system** keeps that Mind running\ncontinuously, safely and under governance.\n\n**Soulseed Apps — the application layer** turns Mind and operating-system capability\ninto real applications.\n\n**Public Reality Infrastructure** carries the public facts and trust that must be\nverifiable across subjects.\n\nSoulAuth occupies the identity-infrastructure position in this stack. It is not a part of SoulseedAGI and not an internal module of SoulseedOS. It keeps its own boundary: it can be composed by SoulseedOS, and it can serve entirely different systems on its own.\n\nSoulseedAGI defines the subject and its Mind, SoulAuth authenticates the subject, SoulseedOS runs and governs it.\n\nSoulAuth's boundary ends at a **trustworthy identity fact**.\n\n| Capability | Core responsibility |\n|---|---|\nActor Identity |\nEstablish who the currently authenticable digital subject is |\nCredential |\nManage what an Actor uses to prove itself |\nAuthentication |\nDecide whether the presented credential holds |\nAuthSession |\nMaintain an authentication state that has been established |\nToken & Federation |\nExpress the identity fact through tokens, OIDC and SSO |\nControl Plane |\nManage identities, credentials, clients and Auth-local RBAC |\nSecurity Protection |\nProtect the credential, authentication, session, token and key lifecycles |\nAudit & Attribution |\nRecord who became the current identity, and through what process |\n\nSoulAuth does not define a Mind and does not stand in for a higher governance system. A successful authentication does not by itself produce a mandate, a business permission, a governance decision, a lease, or the right to act in the real world.\n\nThe shortest form of the boundary:\n\nIdentity answers \"who\", authority answers \"why this Actor may act here and now\".\n\nSoulAuth ships a small RBAC model, but that model governs **SoulAuth's own admin surface\nonly**. Every permission it defines is namespaced `soulauth:`\n\nfor exactly this reason —\na consuming system may well have its own `users.read`\n\n, and the two are different things\nthat happen to share a name. A role granted here is a *claim* about the account, never\nan authorization decision inside the consumer. See\n[Using SoulAuth as an OIDC provider](#using-soulauth-as-an-oidc-provider).\n\nSoulAuth takes **Actor Identity** as the identity root and separates Human Account,\nIdentity Binding and Credential. Credentials enter the authentication core to establish\na trustworthy identity fact, **AuthSession** carries authentication continuity, and\n**Token & Federation** then hands that fact to external consumers as tokens, OIDC, SSO\nand claims.\n\n**Control Plane, Security Protection and Audit & Attribution** cut across the whole\nidentity lifecycle; **Persistence & Infrastructure** underneath provides the data, keys,\nexternal IdPs and adapters that bound the runtime.\n\nThe figure shows logical responsibilities, not a call sequence and not a deployment diagram — everything in it runs in one process today. SoulAuth can keep a small operational surface by default, a Rust service and a SurrealDB. A simple physical deployment does not license mixing the domains inside it:\n\nOne Database ≠ One Domain.\n\nIdentity, Credential, AuthSession, OIDC, Security and Audit still have distinct logical sources, lifecycles and responsibility boundaries even when one database carries them all.\n\n**Standalone.** SoulAuth can act as an independent identity provider for conventional\nWeb, Backend, API and AI / Agent systems, offering complete identity capability through\nauthentication, AuthSession, OIDC, tokens and claims.\n\n```\nSoulAuth\n   ↓\nAny Application\n```\n\n**Within Soulseed.** SoulAuth supplies SoulseedOS with authenticated Actor identity\nfacts through a stable adapter. For a canonical AIActor already defined by SoulseedAGI,\nSoulAuth maintains a controlled identity binding, and never reads, modifies or owns its\nMind.\n\n```\nSoulseedAGI\nCanonical AIActor\n      │\nCanonical Actor Binding\n      ▼\n   SoulAuth\n      │\nAuthenticated Identity\n      ▼\n  SoulseedOS\n```\n\nBoth use the same SoulAuth core. Soulseed is the native integration direction, not a precondition for using SoulAuth.\n\nIdentity infrastructure needs explicit data ownership, strong type boundaries, memory safety and predictable system behaviour. We want Identity, Credential, AuthSession and the other security boundaries to exist not only in the architecture documents, but as constraints the code itself finds hard to violate.\n\nSecurity and audit are not peripheral capabilities added once SoulAuth is deployed; they are part of the identity infrastructure itself. Credential, Authentication, AuthSession, Token, Key, External IdP and audit integrity are all treated as explicit security boundaries, with continuous protection built around MFA, lockout, replay protection, token reuse detection, key lifecycle and tamper-evident audit.\n\nThe concrete posture is in [Security posture](#security-posture) below; the reporting\npath for vulnerabilities is in [SECURITY.md](/TrantorLabs/SoulAuth/blob/main/SECURITY.md).\n\nEverything from here on is operational: how to run it, what it exposes, how it is tested, and where it is still incomplete.\n\n```\naxum 0.6 · SurrealDB 3.0 · 72 paths / 85 operations · ~24k lines\n188 unit tests (no external dependencies) · 27 integration groups / 355 assertions\n```\n\n| Area | What's covered |\n|---|---|\nAccounts |\nRegistration, login, email verification, password reset, account status (Active / Inactive / Suspended / Deleted), membership tiers |\nCredentials |\nArgon2 password hashing, password policy (length + character-class rules), first-password initialisation for accounts created via OAuth |\nThird-party sign-in |\nGoogle and GitHub. Both optional — an instance that only wants email/password configures neither |\nMFA |\nTOTP (RFC 6238) with QR provisioning, single-use backup codes, replay rejection via a step watermark |\nSessions |\nServer-side session records, single logout, global logout (also revokes issued OIDC tokens and every browser session), suspension revokes both |\nOIDC provider |\nDiscovery, JWKS, authorization code + PKCE (S256 only), refresh with rotation, userinfo, RP-initiated logout, client management API |\nAI actors |\nEd25519 challenge–response: no email, no password, no user row. Several active keys per identity, so each machine holds its own and the log records which key authenticated |\nRBAC |\nRoles, permissions, user/role and role/permission assignment — scoped to SoulAuth's own admin surface |\nProtection |\nPer-endpoint rate limiting shared across replicas, account lockout on both user and IP dimensions, CORS allow-list |\nAudit |\nActivity log, security metrics, security report, system health |\n\nRequires a running SurrealDB and a Rust toolchain (edition 2021).\n\n```\n# 1. Schema and seed data — the application performs no DDL of its own\nsurreal import --endpoint http://127.0.0.1:8000 --user root --pass root \\\n    --namespace auth --database main schema.sql\nsurreal import --endpoint http://127.0.0.1:8000 --user root --pass root \\\n    --namespace auth --database main initial_data.sql\n\n# 2. Minimal configuration — four variables, nothing else is required\nexport JWT_SECRET=$(openssl rand -hex 32)   # at least 32 characters\nexport APP_URL=http://localhost:8080        # loopback keeps dev gates open\nexport SMTP_HOST=127.0.0.1\nexport SMTP_FROM=noreply@localhost\n\n# 3. Run\ncargo run\n```\n\n`APP_URL`\n\nis the **public** address, not the listen address (that is `BIND_ADDR`\n\n,\ndefault `0.0.0.0:8080`\n\n). It determines the OIDC issuer, the prefix of links in\noutgoing mail, and whether session cookies carry `Secure`\n\n.\n\nPointing `APP_URL`\n\nat a non-loopback host switches on the production gates —\nsee [Security posture](#security-posture) and\n[DEPLOYMENT.md](/TrantorLabs/SoulAuth/blob/main/DEPLOYMENT.md).\n\nThere is no default account. A fresh instance prints a one-time token in its startup log\n(at `WARN`\n\n, so it is visible at the default level); use it to create the first\nadministrator without touching the database:\n\n```\n# WARN No administrator found. Bootstrap token for this process: 7f3a…\ncurl -X POST http://localhost:8080/api/bootstrap/admin \\\n  -H 'Content-Type: application/json' \\\n  -d '{\"token\":\"7f3a…\",\"email\":\"you@example.com\",\"username\":\"admin\",\"password\":\"CorrectHorse42!\"}'\n\n# Then log in for a session token\ncurl -X POST http://localhost:8080/api/auth/login \\\n  -H 'Content-Type: application/json' \\\n  -d '{\"email\":\"you@example.com\",\"password\":\"CorrectHorse42!\"}'\n```\n\nThe gate closes permanently once an administrator exists, and returns the same response for a wrong token as for a closed gate.\n\nEvery endpoint returns the resource itself — there is no `{success, data, message}`\n\nenvelope. Actions that produce no resource answer `204 No Content`\n\n.\n\n```\nGET /api/auth/me        →  200  {\"id\":\"…\",\"email\":\"…\",\"is_admin\":true}\nGET /api/rbac/roles     →  200  [{\"name\":\"admin\",\"permissions\":[…]}, …]\nPOST …/roles/assign     →  204  (no body)\nerror                   →  4xx/5xx  {\"error\":\"Invalid credentials\"}\n```\n\nThe OIDC endpoints (`/.well-known/openid-configuration`\n\n, `/jwks`\n\n, `/token`\n\n,\n`/userinfo`\n\n, `/authorize`\n\n) return the shapes their specs mandate — including\n`{\"error\":\"invalid_grant\",\"error_description\":\"…\"}`\n\non the token endpoint.\nThat is the one deliberate exception: wrapping them would break every standard\nOIDC client library.\n\n85 operations over 72 paths. `contracts/openapi.yaml`\n\nis the authoritative list and\n`tests/conformance.rs::j4`\n\nholds it against the route table in both directions; this is\nthe shape of it.\n\n| Prefix | Operations | Covers |\n|---|---|---|\n`/api/auth` |\n21 | register, login, admin login, logout, logout-all, sessions, email verification and resend, password reset, first-password initialisation, MFA (5), OAuth entry and callback for two providers |\n`/api/rbac` |\n17 | role and permission CRUD, assignment in both directions, self permission checks |\n`/api/oidc` |\n12 | discovery, JWKS, authorize, token, userinfo, logout, plus the client management API |\n`/api/actors` |\n9 | AI actor registration, credential add and revoke, challenge, authenticate, self-introspection |\n`/api/me` |\n7 | own profile, preferences and activity log |\n`/api/users` |\n7 | admin reads plus account-status and membership writes |\n`/api/audit` |\n5 | dashboard, activity summary, security metrics, security report, system health |\n`/api/security` |\n2 | lockout status query, manual unlock (user or IP) |\n`/api/bootstrap` |\n1 | create the first administrator with the one-time startup token |\n`/api/ops` |\n1 | membership overview |\n`/.well-known` |\n1 | discovery document at the root path |\n`/health` |\n1 | liveness probe (outside the rate limiter) |\n\nEvery endpoint is exercised by the integration suite. Representative flows:\n\n```\n# Register and log in\ncurl -X POST localhost:8080/api/auth/register -H 'Content-Type: application/json' \\\n     -d '{\"email\":\"a@example.com\",\"password\":\"CorrectHorse42!\",\"username\":\"alice\"}'\n\ncurl -X POST localhost:8080/api/auth/login -H 'Content-Type: application/json' \\\n     -d '{\"email\":\"a@example.com\",\"password\":\"CorrectHorse42!\"}'\n# → {\"token\":\"…\",\"user\":{…}}\n\n# Use the token\ncurl localhost:8080/api/auth/me -H \"Authorization: Bearer $TOKEN\"\n\n# Log out — the token is rejected immediately afterwards, not at cache expiry\ncurl -X POST localhost:8080/api/auth/logout -H \"Authorization: Bearer $TOKEN\"\n```\n\nThe decisions below are the ones worth knowing before you deploy, because each of them is a place where the obvious implementation is wrong in a way that does not announce itself.\n\n**No ID token without** If the authentication session reference cannot be resolved, SoulAuth refuses to sign rather than emitting a token with the claim missing. Consumers rely on`sid`\n\n.`sid`\n\nto tie a token to a revocable session; a token without it looks valid and cannot be revoked.**Account status is an allow-list.** Only`Active`\n\npasses. An unrecognised status is treated as unusable. The inverse — \"anything not explicitly listed as bad is fine\" — turns any future status variant into a silent bypass.**Production secrets are mandatory, not advised.** When`APP_URL`\n\nis not a loopback address, a missing OIDC signing key or MFA encryption key refuses the process rather than warning. Both failures otherwise surface long after startup: the first at the next restart, the second at the next`JWT_SECRET`\n\nrotation.**Plaintext OAuth endpoints are rejected** unless they point at loopback.**Unconfigured providers return 501**, not a confusing OAuth error from an exchange attempted with placeholder credentials.\n\nSensitive endpoints — login, registration, password reset, email verification — share their counters through the database. Without that, an N-replica deployment hands an attacker N times the allowance.\n\nThe general API limit stays in-process: putting a database round-trip on the hot path would make the limiter the bottleneck. The line is self-maintaining — anything registered with an explicit endpoint rule gets shared counting.\n\nOne consequence worth internalising: **restarting a replica no longer clears a\nquota**. That is the point (a restart must not work as a jailbreak), but it\nsurprises people during incident response.\n\n- ID tokens are RS256 and verifiable offline through JWKS. Access tokens are opaque random strings — they carry no claims and cannot be verified by a consumer. Handing a consumer the wrong one produces an authentication failure indistinguishable from expiry.\n`id_token_lifetime`\n\nis hard-clamped to 300 seconds on both create and update.- Refresh tokens rotate on every use, and replaying a consumed one is treated as\na leak signal:\n**all tokens for that user and client are revoked**. - Client secrets are returned once, at creation. Reads afterwards return a mask.\n- TOTP secrets are encrypted at rest (ChaCha20-Poly1305); backup codes are Argon2 hashes.\n\n- SoulAuth\n**does not terminate TLS**. Put it behind a reverse proxy; see[Deployment](https://soulauth.trantorlabs.sg/operate/deployment#reverse-proxy). - It performs\n**no DDL**. Schema changes go through`schema.sql`\n\nby hand, so the application account never needs schema privileges. - Mail delivery failures are logged, not surfaced to the caller. Registration succeeds even when the verification mail cannot be sent.\n\nTwo layers with different jobs. Neither substitutes for the other.\n\n```\ncargo test              # 188 unit tests, no external dependencies\ncargo build && ./tests/integration.sh   # 27 groups, 355 assertions\n```\n\n**Unit tests** cover pure logic and consistency invariants — permission names\nmatching the seed data, endpoint path shapes, configuration validation, token\nclaim construction.\n\n**Integration tests** run a real SurrealDB, a real service process, and two\ndependency-free stand-ins (`tests/smtp_sink.py`\n\nreceives mail,\n`tests/mock_oauth.py`\n\nplays Google and GitHub). They assert **contract-level\nbehaviour that compiles fine when broken**:\n\n- permission grants and revocations round-trip\n*to the database*, rather than merely returning success - concurrent failed logins do not lose count under read-modify-write\n- rate limits are counted per route template, not per literal path\n- a second replica sharing the database honours the first replica's quota\n- verification and reset mails arrive, contain a working link, and contain neither the password nor the signing key\n- the OAuth callback creates or links an account, refuses unverified addresses, and never redirects outside the service\n- a confidential client can authenticate by both\n`client_secret_post`\n\nand`client_secret_basic`\n\nUseful switches: `KEEP_WORK=1`\n\npreserves logs, mailbox and the last response\nbody; ports are overridable via `SURREAL_PORT`\n\n/ `APP_PORT`\n\n/ `SINK_PORT`\n\n/\n`OAUTH_PORT`\n\n/ `APP2_PORT`\n\n.\n\nThe same instance serves standalone use and provider use — there is no mode switch. A consuming system is simply another registered client.\n\nThe division of labour is the part that gets misconfigured:\n\n| Component | Role | Needs the client secret? |\n|---|---|---|\n| A server-side component (BFF) | Runs the authorization code flow, holds the refresh token, renews the ID token | Yes |\n| The consuming system | Verifies the ID token's signature, `iss` , `aud` , `exp` , `sid` via JWKS |\nNo — it never exchanges anything |\n| The browser | Carries the ID token to the consumer | No |\n\nTwo consequences that cost debugging time when missed:\n\n, not to the resource server. Getting this wrong fails at the callback step, not at configuration time.`redirect_uris`\n\nbelongs to whoever performs the exchange**A pure SPA cannot hold a client secret.** With ID tokens capped at 300 seconds, the cap itself presumes a server-side session holder. Register a confidential client and add a BFF rather than falling back to a public client.\n\nRegistration, the exact parameters a consumer needs, and three behaviours an\nintegrator cannot discover without reading the source are documented under\n[Register a client](https://soulauth.trantorlabs.sg/integrate/register-a-client) and\n[OIDC and clients](https://soulauth.trantorlabs.sg/reference/oidc-and-clients).\n\nFour variables are required: `JWT_SECRET`\n\n, `APP_URL`\n\n, `SMTP_HOST`\n\n, `SMTP_FROM`\n\n.\nEverything else has a default or is genuinely optional — including both OAuth\nproviders.\n\nThe full table and the production gates are in [DEPLOYMENT.md](/TrantorLabs/SoulAuth/blob/main/DEPLOYMENT.md).\nReverse-proxy and multi-replica notes, and a troubleshooting index organised by\n*symptom that points the wrong way*, are on the documentation site:\n[Deployment](https://soulauth.trantorlabs.sg/operate/deployment) and\n[Troubleshooting](https://soulauth.trantorlabs.sg/operate/troubleshooting).\n\n```\nsrc/\n  main.rs          composition root: router assembly, background tasks\n  config.rs        environment parsing and validation (startup gates live here)\n  error.rs         AuthError and its HTTP mapping\n  models/          domain types; models/permission.rs is the single source\n                   of truth for permission names\n  routes/          HTTP layer, one module per API group\n  services/        business logic: auth, oidc, rbac, mfa, rate_limiter,\n                   account_lockout, audit_logger, database, email\n  utils/           JWT extraction, crypto, validation, middleware\nschema.sql         table and field definitions — authoritative\ninitial_data.sql   roles, permissions, seed accounts; idempotent\ntests/\n  conformance.rs   architecture invariants asserted against schema and source\n  integration.sh   contract-level suite\n  deployment_walkthrough.sh\n                   executes DEPLOYMENT.md from an empty database to a usable admin\n  smtp_sink.py     zero-dependency SMTP receiver\n  mock_oauth.py    zero-dependency Google/GitHub stand-in\n  totp.py          RFC 6238 code generation, self-checked against the RFC vectors\nDEPLOYMENT.md      deployment steps and the environment-variable reference\nDEPLOYMENT.zh-CN.md\n                   the same, in Chinese\n```\n\n**The conformance suite carries 9 invariants that do not hold yet.** They are`#[ignore]`\n\nd rather than deleted, each labelled with the stage it belongs to, and`cargo test --test conformance -- --ignored`\n\nprints the list. They cover identity, credentials, audit and repository separation.**No front-end.** SoulAuth is an API. Mail links and post-OAuth redirects point at paths under`APP_URL`\n\n—`/verify-email`\n\n,`/reset-password/{token}`\n\n,`/login`\n\n,`/oauth/callback`\n\n,`/initialize-password`\n\n. The first three are overridable (`VERIFY_EMAIL_PAGE_URL`\n\n,`RESET_PASSWORD_PAGE_URL`\n\n,`LOGIN_PAGE_URL`\n\n); the last two are fixed paths.`GET /api/me/profile`\n\nand`/api/me/preferences`\n\nreturn 404 before the corresponding`POST`\n\ncreates the record, rather than an empty object.- Registration returns 409 on a duplicate address, which allows probing whether an address is registered. Password reset deliberately does not — the two differ, and the inconsistency is a usability trade-off rather than an oversight.\n- ID token lifetime is capped at 300 seconds for\n**every** client, not only for consumers that asked for it. - No RFC 7662 token introspection. Consumers learn about revocation at token expiry, not immediately.\n\n| Running in five minutes |\n|\n\n[Integration path](https://soulauth.trantorlabs.sg/start/integration-path)[Authorization Code flow](https://soulauth.trantorlabs.sg/integrate/authorization-code-flow)[Production checklist](https://soulauth.trantorlabs.sg/operate/production-checklist)[API reference](https://soulauth.trantorlabs.sg/reference/api-conventions)Deployment steps live in [DEPLOYMENT.md](/TrantorLabs/SoulAuth/blob/main/DEPLOYMENT.md) — that file is what\n`tests/deployment_walkthrough.sh`\n\nexecutes on every push.\n\nSoulAuth's goal is not to lock identity capability inside one application, model or ecosystem. It aims to be identity infrastructure that can be deployed independently, rests on open standards, and composes with other systems through a stable contract. A consumer should never need to read SoulAuth's private database, nor depend on its internal implementation, to use it correctly.\n\nSoulAuth is built by **TRANTOR LABS, Singapore**. What TRANTOR LABS works on is not a\nsingle AI product but the more basic question of the AGI era: once intelligence becomes\na general capability, how should subject, judgment, identity, accountability,\ngovernance and public reality be organised into infrastructure that actually runs.\n\nPhilosophy defines the problem; engineering verifies the answer.\n\nApache-2.0. See [LICENSE](/TrantorLabs/SoulAuth/blob/main/LICENSE) and [NOTICE](/TrantorLabs/SoulAuth/blob/main/NOTICE).\n\nKnown dependency advisories and why they are not reachable in this codebase are\ndocumented in [SECURITY.md](/TrantorLabs/SoulAuth/blob/main/SECURITY.md) — worth reading before you file an\nissue about `cargo audit`\n\noutput.\n\n[CONTRIBUTING.md](/TrantorLabs/SoulAuth/blob/main/CONTRIBUTING.md) covers the three commands to run before opening a\npull request, and the handful of places where a number in this repository is an\nassertion rather than decoration. [CHANGELOG.md](/TrantorLabs/SoulAuth/blob/main/CHANGELOG.md) records what changed and\nwhat an upgrade requires.", "url": "https://wpnews.pro/news/soulauth-rust-identity-infrastructure-for-humans-and-ai-agents", "canonical_source": "https://github.com/TrantorLabs/SoulAuth", "published_at": "2026-09-02 10:05:12+00:00", "updated_at": "2026-09-02 10:22:33.429932+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "ai-safety"], "entities": ["TRANTOR LABS", "SoulAuth", "SoulseedOS", "SoulseedAGI"], "alternates": {"html": "https://wpnews.pro/news/soulauth-rust-identity-infrastructure-for-humans-and-ai-agents", "markdown": "https://wpnews.pro/news/soulauth-rust-identity-infrastructure-for-humans-and-ai-agents.md", "text": "https://wpnews.pro/news/soulauth-rust-identity-infrastructure-for-humans-and-ai-agents.txt", "jsonld": "https://wpnews.pro/news/soulauth-rust-identity-infrastructure-for-humans-and-ai-agents.jsonld"}}