SoulAuth: An Actor-native Identity Architecture and Rust Reference Implementation for Humans and Long-lived AI Actors

AI summary

Overview

Research area: Digital identity and authentication security architecture for AI systems, positioned within AI Safety & Ethics (cs.CY) and sociotechnical infrastructure research.

Technical level: Intermediate — the paper is conceptually dense but written in plain architectural language; readers do not need deep cryptography or protocol expertise, though familiarity with identity concepts (accounts, credentials, OAuth clients, sessions) helps considerably.

Scope (one sentence): The paper argues that persistent identity in systems shared by humans and long-running AI must be anchored to a single "canonical continuity boundary" called an ActorIdentity, and it backs that claim with a ten-invariant model, a logical responsibility architecture, and a partially conformant open-source Rust implementation.

What This Paper Is About

Modern identity systems contain many objects that carry identifiers — user accounts, credentials, OAuth clients, service accounts, workload identities, and authentication sessions — each designed to answer a different question. The problem arises when AI systems live long enough to outlast their credentials, clients, sessions, and runtimes: if any of those peripheral objects is treated as "the identity," then rotating a credential or restarting a workload silently creates a new subject, and past authentication events get misattributed.

The paper's goal is to place the continuity boundary one level above these objects, at an ActorIdentity that both humans and long-lived AI actors can occupy as first-class identity subjects, without unifying their credentials, authentication methods, authority, or legal status.

Key Contributions

1. Philosophical Engineering as a method. Rather than starting from a new authentication component, the authors begin with conceptual clarification of what should count as a persistent subject, then translate that judgment into an ontology, invariants, lifecycle semantics, system responsibilities, code, and conformance evidence.

2. The Actor-native Identity security architecture. The paper defines ActorIdentity as the canonical continuity boundary and formalizes ten Canonical Invariants (I1–I10) plus a Logical Responsibility Architecture that separates identity, authentication, auth sessions, protocol projection, control, security, and audit from any specific deployment topology.

3. A security analysis of identity continuity versus authentication trust continuity. The paper distinguishes "the same actor persists" from "the current request may still rely on a prior proof," and identifies "successful authentication attributed to the wrong persistent subject" as a core failure class, with misattribution modes involving credentials, clients, runtime instances, bindings, and authority boundaries.

4. A Rust reference implementation with inspectable conformance evidence. SoulAuth v0.1.0 is released open-source (Apache-2.0) and evaluated through Architecture Conformance, negative testing, a fixed source revision, and CI evidence that links architectural claims to PASS, PARTIAL, and FAIL states.

Main Findings

• The continuity boundary belongs above peripheral objects. ActorIdentity is not a renamed User object. It persists while credentials rotate, clients change, sessions begin and end, bindings are created or revoked, and runtimes are replaced. Only the actor itself defines who the actor is.

• Lifecycle independence is the mechanism, not immutability. Credential rotation is not actor replacement. Binding revocation is not actor retirement. Auth session revocation is not credential revocation. Client disable is not actor suspension. Actors remain the same because the system can still resolve them after legitimate peripheral change — not because nothing ever changes.

• Human and AIActor status is symmetric at the identity layer only. Per invariant I7, an AI actor's status as an identity subject does not depend on a human account, and does not require the same credentials, methods, lifecycles, or authority. What is unified is subjecthood, not authentication flow.

• Authentication results do not confer authority. The paper maintains three hard separations: Authentication ≠ Authority, Assurance Level ≠ Freshness, and Higher Assurance ≠ Greater Authority. A valid session does not mean a proof is fresh enough for every new trust requirement.

• Historical attribution must be anchored to the actor, not to current state. Invariant I9 states that current mutable identity state must not redefine historical attribution, and I10 forbids reassigning a retired ActorIdentity identifier. If audit records resolve through current profile or binding state, changing that state retroactively rewrites the past.

• Four distinct fact types must not substitute for one another. Canonical domain state (current identity facts), trusted projection (tokens and claims for relying parties), and historical evidence (audit records) all relate through ActorIdentity but none substitutes for another; likewise One Database ≠ One Domain and Persistence Schema ≠ Canonical Ontology.

• The reference implementation is only partially conformant. Conformance evaluation on the fixed SoulAuth v0.1.0 release shows core boundaries realized — first-class subject status for humans and AI actors, separation of Client from Actor, and separation of Authentication from Authority — but gaps remain in unified credential modeling and in historical attribution anchored to ActorIdentity. The authors explicitly report partial, not full, conformance.

• Identity-binding is relationship, not equivalence. A binding declares a constrained correspondence between identity domains; it does not merge sources of truth, and similar emails, display names, or subject strings cannot by themselves establish identity equivalence.

Methodology in Plain English

The authors work in two layers. First, they do conceptual work: they take the existing identity vocabulary — accounts, credentials, clients, workloads, sessions — and ask what question each object actually answers. From that, they decide which object should serve as the persistent subject, then write that decision down as a set of invariants that hold regardless of database, protocol, or deployment choice.

Second, they build the thing. The invariants become object boundaries, lifecycle rules, and a set of named logical responsibilities (identity domain, authentication core, auth session, tokens and federation, control plane, security, audit and attribution, persistence). A Rust implementation turns those responsibilities into a running system.

Third, they test whether the code actually honors the design. Architecture Conformance links specific architectural claims to machine-readable contracts, runtime behavior, negative tests, and CI output at a pinned source revision, producing an auditable verdict of PASS, PARTIAL, or FAIL per claim. That last step is what lets the paper report partial rather than aspirational conformance.

Why This Matters

The paper addresses a gap that appears only once AI systems become long-lived. Account, credential, client, and workload abstractions all work well in their own domains; the failure mode is not that they break, but that a system picks one of them as the default subject and loses the ability to say reliably who was authenticated. For research, the paper offers a reusable framing — subject boundary as an explicit architectural choice — plus a conformance methodology that could be applied to other identity and agent-governance systems.

Real-world applications:

• Enterprise agent management. An organization deploying long-running AI agents needs credential rotation, client migration, and runtime upgrades without those operations creating new audit subjects or orphaning the agent's history.

• Accountability and audit in automated workflows. When an automated action must be traced back to a responsible principal months later, audit records need to resolve to a stable actor identity rather than to whatever credential or session was in use at the time.

• Human–AI collaboration platforms. Shared infrastructure where human accounts and AI actors coexist can use one higher-level subject model while keeping authentication methods and lifecycles separate for each kind.

• Governance and delegation pipelines. Downstream authorization, delegation, and governance systems get a well-defined "who" to attach permissions and responsibility to, without the identity layer presuming to decide what that actor may legally or operationally do.

Industry relevance centers on the fact that authentication facts are upstream inputs to accountability, authorization, and audit. If the subject relationship is wrong, a downstream system with otherwise complete governance can still be built on misattributed foundations.

Future Directions

• Close the credential-modeling gap. The paper reports partial conformance, with unified credential modeling identified as an incomplete area. A follow-up could specify a canonical credential abstraction that satisfies the invariants across heterogeneous authentication sources.

• Anchor historical attribution end-to-end. Ensuring audit and attribution records bind to ActorIdentity rather than to reconstructable current state is named as an outstanding gap and is the natural next conformance target.

• Extend federation and cross-domain binding semantics. The paper treats identity bindings as explicit relationships rather than equivalences, but many practical questions about trust contracts between identity domains — revocation propagation, conflicting bindings, external subject churn — remain open.

• Generalize the conformance methodology. Whether the Architecture Conformance approach (claims linked to machine-readable contracts, negative tests, and CI evidence at a pinned revision) can be reused for other identity, agent, or governance architectures is an open and potentially broadly useful question.

Target Audience

Identity and authentication architects, security engineers working on machine and workload identity, and platform teams building infrastructure where humans and long-running AI systems share the same authentication substrate. It is also relevant to researchers in AI governance, accountability, and sociotechnical systems who need a rigorous account of how "who was authenticated" is determined before questions of responsibility can be asked. Readers looking primarily for model-level AI safety, agent capability work, or legal personhood arguments will find this paper explicitly out of scope.

Authors’ abstract

As AI systems move from transient model invocations toward long-lived actors that persist across credentials, clients, sessions, and runtime instances, identity infrastructure must answer a basic question: where should the canonical continuity boundary be placed? This paper introduces Actor-native Identity and presents SoulAuth, an open-source Rust reference implementation for Humans and long-lived AIActors. We argue that any subject that must persist under its own identity and remain independently attributable should have an ActorIdentity that is not replaced by an Account, Credential, Client, AuthSession, IdentityBinding, or runtime instance. SoulAuth therefore treats Humans and long-lived AIActors as first-class identity subjects while keeping authentication distinct from downstream authority. Methodologically, we use a Philosophical Engineering approach that translates conceptual analysis of subjecthood into identity objects, invariants, lifecycle semantics, system responsibilities, implementation boundaries, and inspectable conformance evidence. Evaluation against the fixed SoulAuth v0.1.0 artifact shows that the implementation realizes core boundaries including Human/AIActor first-class identity status, Client/Actor separation, and Authentication/Authority separation, while gaps remain in unified Credential modeling and historical attribution anchored to ActorIdentity. We therefore report partial, not full, architecture conformance.