PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Kun Yuan, Harold Wang, Echo Li, Egusi Gui, Kiki Hu, Lucas Luo, Magnus Hu

arXiv:2609.11258v1cs.CYcs.AIcs.CR

TL;DR

Long-lived AIActors can persist across changing credentials, clients, sessions, and runtimes, raising the question of where identity continuity belongs. The paper proposes ActorIdentity as that boundary and develops SoulAuth through Philosophical Engineering. Its fixed v0.1.0 evaluation finds core boundaries realized but reports partial, not full, conformance.

  • Problem

    When credentials, clients, sessions, and runtimes change, identity infrastructure must determine which object remains the persistent subject, since existing identity objects serve different roles.

    Source: §1 · p. 2

  • Method

    The paper uses Philosophical Engineering to translate analysis of subjecthood into ActorIdentity-centered boundaries, implementation, and conformance evidence.

    Source: §10 · pp. 31–32

  • Results

    SoulAuth v0.1.0 realizes several core Actor-native boundaries but remains partially—not fully—conformant, with gaps in unified Credential modeling and ActorIdentity-anchored historical attribution.

    Source: §10 · p. 32

  • Takeaways & Limitations

    ActorIdentity provides a stable subject boundary around which credentials, protocols, runtimes, and higher-layer mechanisms can build relationships.

    Source: §10 · p. 32

    SoulAuth is limited to identity and authentication; it does not define AI consciousness, legal personhood, delegation, governance, or execution Authority.

    Source: §10 · p. 32

Abstract

from arXiv · show

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.

1 Introduction

Long-lived AIActors raise the question of which identity object should persist as credentials, clients, sessions, and runtimes change. The paper makes ActorIdentity that continuity boundary and separates identity from authentication and downstream authority.

1 Introduction

  • When peripheral objects change, identity infrastructure needs a persistent subject so authentication and historical attribution still refer to the same “who.”The paper frames this as both a computer-systems and sociotechnical infrastructure problem for accountability, authorization, governance, and audit.Source: §1 · p. 2
  • Actor-native Identity makes ActorIdentity the canonical continuity boundary, separating it from Account, Credential, Client, IdentityBinding, AuthSession, protocol projections, and runtime.Humans and long-lived AIActors share a higher-level identity model while retaining different credentials, authentication methods, and lifecycles.Source: §1 · pp. 2–3
  • The shared requirement for Humans and AIActors is a stable, independently attributable subject—not a shared authentication method or a claim about AI social or legal status.The paper uses Philosophical Engineering to clarify subjecthood and translate that judgment into identity objects, invariants, lifecycle rules, system responsibilities, and conformance evidence.Source: §1 · p. 3
  • SoulAuth authenticates ActorIdentity and passes verified identity facts downstream; successful authentication does not itself establish permissions, governance decisions, or execution eligibility.Authorization, delegation, governance, and other domains determine what the subject may do.Source: §1 · p. 3
  • The paper provides an open-source Rust reference implementation and an Architecture Conformance mechanism linking selected claims to machine-readable contracts, runtime behavior, and verification evidence.The implementation makes architectural decisions compilable, deployable, and inspectable, without claiming that Rust proves the architecture correct.Source: §1 · p. 4
  • The paper’s scope is identity and authentication; it does not address AI consciousness or legal personhood or merge identity, authorization, governance, and execution into one system.Its stated design principle is to determine who the Actor is before determining how that Actor proves itself.Source: §1 · p. 4

2 Problem Model, Design Requirements, and Boundaries

This section asks when a computational entity needs an independent identity subject and how that subject remains identifiable across changing objects and domains. It distinguishes identity, authentication, and Authority rather than collapsing their separate roles.

2.1 Misaligned Identity Objects

  • Account, Credential, Client, Workload, and Service Account answer different questions, so none should define a persistent subject merely by existing.For long-running AI systems, changing credentials, clients, sessions, or runtimes make those objects poor substitutes for the Actor they relate to.Source: §2.1 · p. 5, §2 · p. 5

2.2 Minimal Engineering Definition and Identity Requirements of an AIActor

  • An AIActor is an identity-layer engineering category, not a claim about consciousness or legal status; it needs its own identity when it authenticates independently and must retain stable historical attribution.A single-request computation whose responsibility remains with an upstream application identity may not need its own identity; an AIActor must not depend on a HumanAccount for a complete identity.Source: §2.2 · p. 5

2.3 Identity Continuity and Historical Attribution

  • Identity continuity allows peripheral state to change while the system continues recognizing the same Actor, and prevents current state changes from reinterpreting past authentication facts.The design requires historical events to remain associated with the ActorIdentity to which they were attributed when they occurred.Source: §2.3 · pp. 5–6

2.4 Cross-Domain Identity Relationships Must Be Explicit

  • IdentityBinding represents an explicit, constrained cross-domain correspondence; similar identifiers do not establish equivalence, merge domains, or replace authentication.Each identity domain retains ownership of its identity facts and definitional authority.Source: §2.4 · p. 6

2.5 Authentication Boundary and Non-Goals

  • Identity defines the subject, authentication tests whether current evidence proves it, and Authority determines what the authenticated subject may do in context.SoulAuth can tell a relying system which authenticated Actor a request comes from, but does not infer permissions or governance or execution Authority; it does not define AI consciousness or legal personhood.Source: §2.5 · p. 6

3 Actor-native Identity Model

ActorIdentity is the canonical continuity boundary for Humans and AIActors; accounts, credentials, clients, bindings, and sessions retain separate responsibilities and lifecycles.

3.1 ActorIdentity: The Canonical Continuity Boundary

  • ActorIdentity anchors “who” within SoulAuth; Credentials, Clients, AuthSessions, and Bindings may change without redefining the Actor, while external identities require explicit mapping.Source: §3.1 · p. 7

3.2 ActorKind and First-Class Identity-Subject Status

  • Humans and AIActors have equal first-class identity-subject status, without requiring the same Credentials, authentication methods, lifecycles, or Authority.Source: §3.2 · p. 7

3.3 Identity Objects Around ActorIdentity

  • HumanAccounts carry account state, Credentials prove identity, Clients participate in protocols, Bindings relate identity domains, and AuthSessions maintain bounded authentication continuity.Source: §3.3 · pp. 8–9

3.4 Object Relationships and Lifecycles

  • Independent object lifecycles allow peripheral changes without changing Actor continuity; retirement ends future valid use, and identifiers cannot be reassigned without compromising historical attribution.Source: §3.4 · p. 9

3.5 Canonical Invariants

  • The ten canonical invariants make ActorIdentity the continuity boundary, preserve Human and AIActor subject parity, separate Authentication from Authority, and prevent peripheral state from redefining identity.Source: §3.5 · p. 10

4 SoulAuth System Architecture

SoulAuth organizes identity infrastructure around durable logical responsibilities rather than deployment units. Identity, authentication, projections, audit, and persistence remain distinct and preserve their boundaries.

4.1 Organizing Identity Infrastructure by Logical Responsibility

  • SoulAuth defines durable logical responsibility domains, not a fixed runtime pipeline or deployment topology; units may be grouped or split while preserving those boundaries.Source: §4.1 · pp. 10–11

4.2 Identity Domain and Authentication Core

  • The Identity Domain maintains ActorIdentity and answers “who,” while the Authentication Core evaluates proof; authentication resolves to an ActorIdentity but cannot redefine it.Source: §4.2 · pp. 11–12

4.3 Authentication State and Protocol Projection

  • AuthSession carries an established authentication fact for a bounded period, while Tokens and federation project established facts outward without becoming their source of truth.Source: §4.3 · p. 12

4.4 Control, Security, and Audit

  • Control manages SoulAuth, security protections span the lifecycle, and audit preserves historical identity and authentication evidence distinct from current state and trusted projections.Source: §4.4 · pp. 12–13

4.5 Persistence and Infrastructure

  • Persistence and infrastructure carry domain semantics without owning them: logical domains can share databases or span stores, and schemas cannot redefine the canonical ontology.Source: §4.5 · pp. 13–14

5 Identity Continuity and Authentication Semantics

SoulAuth separates persistent identity from proof and the trust placed in prior authentication. Human and AIActor paths may differ, while authentication facts remain bounded by context and lifecycle rules.

5.1 Authentication Runtime Model

  • Authentication evaluates whether current evidence proves an already resolved ActorIdentity; Credentials, submitted evidence, results, and AuthSessions remain distinct objects with different timescales.Source: §5.1 · p. 14

5.2 Authentication Paths for Humans and AIActors

  • Humans and AIActors may use different authentication sources, Credentials, and evidence, but both paths must verify a clearly identified ActorIdentity under defined semantics.Source: §5.2 · pp. 14–15

5.3 Authentication Result, Freshness, and AuthSession

  • Authentication results carry context such as method, time, assurance, and freshness; assurance is not Authority, and an unexpired AuthSession does not guarantee sufficient freshness.Source: §5.3 · pp. 15–16

5.4 Identity Continuity and Authentication Trust Continuity

  • Identity continuity can persist through credential, session, or runtime changes, while reliance on earlier authentication remains subject to explicit lifecycle rules, freshness, and current trust conditions.Source: §5.4 · p. 16

6 Rust Reference Implementation

SoulAuth carries Actor-native Identity into a runnable Rust system while preserving the architecture’s object and responsibility boundaries. Its implementation keeps ActorIdentity as the continuity boundary and separates it from accounts, credentials, clients, sessions, protocol projections, and persistence.

6.1 From Actor-native Identity Architecture to a Real System

  • SoulAuth implements Actor-native Identity in Rust, carrying architectural object and responsibility boundaries into data structures, runtime logic, protocol entry points, and persistence.The implementation is intended to make the identity model compilable, deployable, and inspectable, rather than allowing implementation details to redefine the architecture.Source: §6.1 · p. 18

6.1.1 Implementation Overview

  • The public reference implementation includes ActorIdentity, HumanAccount, native AIActor authentication, Client, AuthSession, OIDC, audit, and Architecture Conformance.The paper bounds its evaluation to a fixed source revision; exact release details are consolidated in Artifact Availability.Source: §6.1.1 · p. 18, §6.4 · p. 21

6.2 From Identity Model to Implementation Objects

  • ActorIdentity remains the canonical continuity boundary, while HumanAccount, Credential, Client, IdentityBinding, and AuthSession retain separate state and lifecycles.Human and AIActor paths may use different credentials or protocol flows, but resolve to ActorIdentity as the common identity layer.Source: §6.2 · pp. 18–19
  • The architecture-to-implementation mapping preserves semantic boundaries without requiring Rust modules to mirror the architecture diagram one-to-one.Protocol objects must not acquire subject-defining authority through implementation convenience.Source: §6.2 · p. 19, Figure 7 · p. 19

6.3 Runtime Realization of Key Architectural Boundaries

  • At runtime, Credential proves a subject’s identity without redefining ActorIdentity, while Client participation remains distinct from Actor authentication.AIActors can authenticate under their own ActorIdentity without depending on HumanAccount; protocol projections and persistence schemas also do not become the source of truth for ActorIdentity.Source: §6.3 · p. 20

6.4 Rust, Open Source, and Artifact Inspectability

  • Rust’s memory safety, ownership constraints, and type system can reduce some low-level implementation risks, but Rust does not prove the architecture correct.It cannot determine whether an IdentityBinding is semantically correct or automatically ensure authentication stays outside the Authority boundary.Source: §6.4 · p. 20
  • Open-source code makes the architecture-to-implementation mapping independently inspectable, while Rust carries the architecture into a real implementation.The reported implementation and evaluation facts are limited to the fixed v0.1.0 revision and are not generalized to later states of main.Source: §6.4 · pp. 20–21

7 Architecture Conformance and Artifact Evidence

Architecture Conformance tests whether the implementation preserves the claimed identity relationships, not merely whether operations work. On the fixed v0.1.0 revision, core boundaries are realized, but unresolved gaps mean conformance is partial.

7.1 From Architectural Claims to Implementation Evidence

  • Conformance links normative identity claims to concrete implementation surfaces and claim-specific evidence; no single test proves every architectural claim.Evidence may include types, schemas, runtime behavior, state-transition tests, and negative tests, depending on the claim.Source: §7.1 · p. 21

7.2 Conformance Verification of Key Actor-native Identity Invariants

  • Conformance checks target semantic regressions ordinary functional tests may miss, including HumanAccount dependence for AIActors and client_id being treated as Actor Subject.Credential rotation must also preserve ActorIdentity, and authentication results must not grant downstream Authority.Source: §7.2 · p. 22

7.3 Conformance Results on the Fixed v0.1.0 Revision

  • v0.1.0 exhibits partial, not full, architectural conformance; unresolved checks remain despite active checks passing.The evaluation is tied to a fixed source revision and does not generalize to later states of main.Source: §7.3 · pp. 22–23
  • AIActors authenticate without HumanAccount, while v0.1.0 preserves Client/Actor, IdentityBinding/relation, and Authentication/Authority boundaries.These results show first-class Human and AIActor identity status in the authentication path.Source: §7.3 · p. 23
  • Credential separation is incomplete across Human paths, and some historical events still rely on Human-oriented user_id references instead of stable ActorIdentity.AIActor key lifecycles can change independently without replacing the Actor.Source: §7.3 · p. 23

7.4 Inspectable Artifacts and Evidence Boundary

  • The evidence boundary fixes claims, implementation surfaces, tests, and results to SoulAuth v0.1.0, making the reference implementation’s architectural counterparts inspectable.The evidence supports only the claims each item is designed to test, not a generalized claim that passing tests proves correctness.Source: §7.4 · pp. 23–24

8 Security Analysis

SoulAuth’s security analysis centers on whether authentication and related identity facts remain attributed to the correct ActorIdentity. It examines relationship integrity, Authority scope, and time as distinct boundaries.

8.1 Threat Model and Identity Misattribution

  • Authentication can succeed while proving the wrong ActorIdentity, making identity misattribution—not simply failed authentication—the central security concern.The analysis assumes trusted core verification components and persistent state, and asks whether relationships among identity objects remain correct.Source: §8.1 · pp. 24–26

8.2 Identity Relationships and Authentication Integrity

  • Valid cryptographic verification alone is insufficient: Credentials, Clients, and external Subjects must be correctly related to the Actor, proof context, and identity source.Credential binding substitution can misattribute a proof even without theft of the Actor’s original Credential.Source: §8.2 · p. 27

8.3 Authority and Temporal Trust Boundaries

  • Authentication establishes an ActorIdentity under particular conditions, not application or governance Authority; current state changes must not rewrite past attribution or revive invalidated trust.ActorIdentity may persist while Credentials, Bindings, Authentication Results, and AuthSessions change over time.Source: §8.3 · pp. 27–28

9 Related Work and Discussion

SoulAuth builds on established identity and protocol approaches but asks where persistent continuity belongs when Humans and long-lived AIActors share infrastructure. It places that boundary at ActorIdentity while keeping adjacent responsibilities and lifecycles distinct.

9.1 Principal, Protocol Identity, and Workload Identity

  • Principal, OAuth/OIDC, and Workload Identity provide established abstractions; SoulAuth asks which identity object should carry continuity for a long-lived Actor.Protocol Subjects and Workloads have their own roles, while ActorIdentity is the proposed upstream continuity boundary.Source: §9 · p. 28, §9.1 · p. 28

9.2 Persistent AI Agent Identity, Decentralized Identity, and Delegation

  • Identity, Authentication, Authority, Delegation, and Discovery may be composed without collapsing them into one object.SoulAuth’s boundary is prior to authorization, delegation, and discovery mechanisms.Source: §9.2 · pp. 29–30
  • SoulAuth places continuity at ActorIdentity rather than the runtime or Credential, while limiting its scope to identity and authentication rather than mind continuity.It can attribute events across runtime migration to the same ActorIdentity, but does not determine whether Memory, Model, Policy, or Behavior constitutes the same mind.Source: §9.2 · pp. 29–30

9.3 Attribution, Applicability Boundaries, and Research Position

  • ActorIdentity is the canonical continuity boundary, allowing peripheral objects to evolve while providing a stable reference for attribution and downstream accountability.Identity-subject status does not imply equal Authority, capability, responsibility, or legal status, and ActorIdentity is not globally universal.Source: §9.3 · pp. 30–31

10 Conclusion

SoulAuth treats ActorIdentity as the persistent subject behind changing Credentials, Clients, sessions, and runtimes. The fixed v0.1.0 evaluation finds core boundaries implemented but reports partial, not full, architectural conformance.

10 Conclusion

  • ActorIdentity remains the subject across Credential rotation, Client changes, session renewal, and runtime migration, while Humans and long-lived AIActors are first-class identity subjects.HumanAccount, Credential, Client, IdentityBinding, and AuthSession retain separate responsibilities and lifecycles.Source: §10 · p. 31
  • SoulAuth translates conceptual analysis into system boundaries and inspectable conformance evidence, while leaving Authority, legal personhood, consciousness, and Mind Continuity outside its scope.Its responsibility ends at identity and authentication; downstream mechanisms may use the resulting identity facts.Source: §10 · p. 32
  • The fixed v0.1.0 implementation realizes several core Actor-native boundaries, but unified Credential modeling and historical attribution anchored to ActorIdentity remain partially realized.The paper reports substantial reference implementation with partial—not full—architectural conformance.Source: §10 · p. 32

Artifact Availability

The paper binds its evaluation to a fixed public SoulAuth v0.1.0 artifact and points readers to repository and CI evidence. It does not present that metadata as independent certification.

Artifact Availability

  • The fixed artifact identifies SoulAuth v0.1.0, its exact Git commit, release archive, and archive SHA-256.The release date is listed as 2026-09-09.Source: Artifact Availability · p. 32
  • The public repository and CI run provide a traceable entry point for the fixed artifact’s evaluation evidence.The artifact is listed under an Apache-2.0 license.Source: Artifact Availability · p. 33
  • Build, test, conformance, and deployment details are retained in the repository and CI record rather than repeated in the paper; the metadata is not independent artifact certification.The paper describes the evidence path as linking claims, fixed release, implementation evidence, observed results, and disclosed limitations.Source: Artifact Availability · p. 33

Related papers

Loading 2609.11258v1…