We are proud to announce that SoulAuth, one of TRANTOR LABS's AGI infrastructure projects, has reached its first public research and engineering release. The SoulAuth research paper is now available as an arXiv preprint, and the corresponding Rust reference implementation, SoulAuth v0.1.0, has also been released as open source.
Research paper: https://arxiv.org/html/2609.11258v1 Open-source repository: https://github.com/TrantorLabs/SoulAuth
This is the first major theoretical and engineering contribution that TRANTOR LABS, as a research lab focused on foundational AGI infrastructure, is releasing publicly to the field. Its significance is not simply that we have published a paper or opened a code repository. For the first time, we have taken a foundational question about future AGI infrastructure from conceptual definition, identity modeling, and system architecture all the way into a real Rust implementation and inspectable engineering evidence.
This release also marks TRANTOR LABS's formal entry into the engineering release phase of our AGI infrastructure work. If large language models are gradually becoming a general-purpose computational foundation for the intelligence era, what additional infrastructure will be required for AIActors that persist over time, continue to understand and judge, call tools, and act in the real world? SoulAuth is one of our first answers. It begins with a basic question: when Humans and long-lived AIActors enter the same systems and continue to act over time, how do we reliably know who is who?
From “How Does AI Log In?” Back to “Who Is Acting?”
Most identity systems in use today were not designed for long-lived AIActors. They are usually organized around Human Accounts, Credentials, Clients, Sessions, Service Accounts, or Workloads. That structure has served the traditional internet, enterprise software, and cloud environments well.
But as AI moves from one-off model calls toward Actors that can persist, maintain task continuity, call tools across systems, and participate continuously in real-world activity, the existing identity abstractions face a different problem. A long-lived AIActor may rotate Credentials, pass through many AuthSessions, enter through different Clients, migrate across Runtimes, upgrade components, and change execution environments. If all of these surrounding objects can change, what still represents the same Actor?
This is not a problem that can be solved simply by giving an AI another ID. If the Credential itself is treated as the subject, Credential Rotation may appear to create a new identity. If the Session is treated as the subject, continuity disappears when the Session ends. If the Client or Runtime is treated as the subject, migrations, upgrades, and redeployments keep creating new identity boundaries.
When AI is only a short-lived call, these confusions may not be obvious. But once an AIActor begins to act continuously and enters workflows, organizations, and public systems where actions have real consequences, the identity problem becomes an attribution problem: months or even years later, can we still answer reliably, “Who did this?” SoulAuth therefore does not begin with the question of how to make an AI log in. It steps back to a more basic layer of identity infrastructure: what should actually carry identity continuity?
ActorIdentity: Separating the Subject from Accounts, Credentials, and Sessions
SoulAuth's core answer is ActorIdentity. In the SoulAuth identity model, ActorIdentity is the canonical boundary of identity continuity. Humans and long-lived AIActors can each hold their own ActorIdentity and exist as first-class subjects at the identity layer. “First-class subject” is not a claim about legal personhood, nor does it imply that Humans and AIActors share the same rights, capabilities, lifecycles, or authentication methods. It expresses a specific architectural position: if a subject must persist under its own identity and its actions must remain independently attributable, that subject should not be hidden beneath another Account, Credential, Client, or Session.
Accordingly, ActorIdentity is not HumanAccount, not Credential, and not Client or AuthSession. An Account may change, a Credential may rotate, a Session may end, a Client may change, and a Runtime may be upgraded, but none of those changes should by itself mean that the Actor has been replaced.
This is why we describe SoulAuth as Actor-native Identity. It does not solve the problem by adding a type = ai field to a traditional User model. It changes where the identity system is rooted. Instead of first asking what type of account this is, it first asks which subject must persist over time and bear attribution. HumanAccount, Credential, IdentityBinding, Client, and AuthSession still play important roles, but none of them stands in for ActorIdentity itself. On the surface, this may look like a reorganization of identity objects. In practice, it determines whether a long-lived AIActor can have genuine identity continuity across time.
From Identity Continuity to Attribution and Accountability
We place this much emphasis on identity continuity because long-lived AI systems ultimately have to face attribution. If an AIActor's history is scattered across changing API Keys, Sessions, Clients, or Runtimes, a system may preserve a large volume of technical logs and still be unable to determine whether those records belong to the same persistent subject. The logs remain, but the actual “who” may have disappeared at the architectural level.
Once the subject can no longer be identified reliably, the problem does not remain confined to identity. Audit systems no longer know around whom a long-term record should be built. Authorization and governance systems struggle to determine whether they are dealing with the same Actor. When something goes wrong, accountability mechanisms also lose the most basic technical fact they need: who actually performed the action. SoulAuth therefore does not claim to solve the entire problem of AI accountability on its own. It establishes the identity and attribution conditions that accountability requires in order to become possible.
This is also why SoulAuth explicitly separates Identity, Authentication, and Authority. Identity answers “Who is this?” Authentication answers “Has this identity been reliably proven?” Authority answers “May this Actor perform this action here and now?” A successful authentication establishes a trustworthy identity fact. It does not automatically give the Actor the power to transfer funds, deploy code, access sensitive data, call high-risk tools, or act on behalf of an organization. Authorization, Delegation, Governance, and Execution remain responsibilities of downstream systems. SoulAuth's responsibility is to ensure that those systems can at least begin from a stable and trustworthy “who.”
Putting Each Responsibility Back in Its Proper Place
Around ActorIdentity, SoulAuth establishes a clear logical responsibility architecture. The Identity Domain owns identity objects and canonical state related to subject continuity. The Authentication Core validates authentication evidence. AuthSession carries an authentication state that has already been established. Token and Federation express verified identity facts to relying systems. Audit and Attribution preserve evidence related to identity, authentication processes, and historical attribution.
Security and Control operate as cross-cutting capabilities across these lifecycles, while Persistence and Infrastructure provide the data, keys, and external connections required to run the system. We deliberately preserve the semantic boundaries between these responsibilities even when they can all run today inside a single Rust service and even a single database. For us, a simple physical deployment is not a reason to collapse logical responsibilities. A system can have one process while Identity, Credential, Authentication, Session, Projection, and Audit still remain distinct responsibilities. The system can be simple, but the boundaries must remain clear.
The Actor Can Persist, but Authentication Trust Must Be Re-established
SoulAuth also distinguishes Identity Continuity from Authentication Trust Continuity. An Actor can retain the same ActorIdentity over a long period of time, but a system should not permanently trust an authentication state established in the past. A Credential may have rotated, a Session may have expired, a Client may have changed, and a Runtime may have been updated. In those cases, the subject can remain continuous while the authentication evidence must be verified again and trust may need to be re-established.
For that reason, Credential Rotation is not Actor Replacement. Session expiry does not mean that the subject disappears, and a Runtime update should not automatically recreate the historical subject. If every Credential update, Session termination, or Runtime migration creates a new identity subject, a long-running AIActor will eventually fragment into many isolated technical objects inside the system. We may still have complete logs, yet no longer be able to determine reliably whether those actions were performed by the same Actor.
What SoulAuth is trying to preserve is this cross-time thread of subject continuity. When subject continuity is preserved, historical attribution has a chance to remain coherent. When attribution remains stable, audit, governance, and accountability can operate over the same set of identity facts.
From Philosophical Definition to Inspectable Engineering
SoulAuth is also a concrete practice of what TRANTOR LABS calls Philosophical Engineering. When we say philosophy comes before engineering, we do not mean adding a philosophical interpretation after a technical system has already been built. We mean defining the problem clearly before committing the key architecture to code. When engineering confronts questions such as “What is the subject?”, “What must remain continuous?”, and “To whom should history belong?”, ambiguity at the conceptual layer is quickly hardened into ambiguity in the system itself.
We therefore begin by clarifying the relationships among Actor, Account, Credential, Client, Session, and Authority. We then compress those judgments into a set of Canonical Invariants, the structural boundaries that the architecture is expected to preserve over time. Those invariants then enter system responsibilities, Schemas, interfaces, state transitions, and the Rust reference implementation. Finally, Architecture Conformance asks whether the claims made in the paper can actually be located in the implementation surfaces and verification evidence of the codebase.
The research chain can be summarized as follows: conceptual clarification → canonical invariants → system architecture → reference implementation → architecture conformance evidence. The paper and the code play different roles in this chain, but they refer to the same research object. If we claim ActorIdentity ≠ Credential, Client ≠ Actor, or Credential Rotation ≠ Actor Replacement, external researchers should not have to take those statements on faith. They should be able to enter the codebase and inspect the identity model, lifecycles, Schemas, and corresponding tests. For TRANTOR LABS, architecture should not only be explainable. It should also be inspectable.
Why SoulAuth Must Be Open Source
For that reason, open-sourcing SoulAuth is not a communications step added after the research is finished. It is part of the research method itself. We have released the Rust reference implementation and preserved a fixed v0.1.0 research version so that the paper, implementation, and verification evidence can be examined against the same public Artifact. External researchers can begin from an architectural claim in the paper, enter the corresponding version of the code, and inspect where that boundary is implemented and what the current system actually supports.
That inspectability also requires us to expose what is not yet complete. SoulAuth v0.1.0 is not a final system that fully realizes the target architecture. In the paper's Architecture Conformance evaluation, the current version is explicitly described as Partial Conformance. Several important boundaries are already present in the implementation, while clear engineering distance remains in areas such as unified Credential modeling and anchoring historical attribution more completely in ActorIdentity.
We believe this is precisely where Architecture Conformance should matter. If a conformance method can only tell us what has already been completed, but cannot identify the remaining distance between a theoretical claim and the actual code, it is difficult for that method to function as a real research tool. By exposing those gaps, we want SoulAuth to be an engineering research object that can be verified, falsified, and continuously revised from the beginning.
From Research Definition to the Engineering Release of AGI Infrastructure
SoulAuth also carries another meaning for TRANTOR LABS. It marks our transition from researching and defining foundational AGI questions to publicly releasing the infrastructure that attempts to answer them.
We have consistently argued that if future AI is no longer merely a model being called, but becomes an Actor that persists, maintains continuous state, enters organizations, and participates in real-world action, then AGI infrastructure cannot answer only whether the intelligence is powerful enough. We also need to answer how a subject is established, how identity persists, how authentication is performed, how actions are attributed, how Authority is obtained, how systems are operated and governed, and how intelligent subjects ultimately enter public reality. SoulAuth begins with the most basic of these questions: who?
We do not believe an identity system can solve every problem of AGI safety, governance, and accountability. But we do believe that before more intelligent systems begin to act continuously in the world, establishing a stable, clear, verifiable, and attributable subject boundary is a prerequisite for many of the problems that follow to be addressed seriously.
Today, we are making this stage of our research public. The paper is out, the code is open source, and SoulAuth is moving from an internal TRANTOR LABS research design into the public research and engineering space. From this point forward, it can be read, run, inspected, challenged, and improved. For us, that is what should happen when foundational research enters the public world: we define the problem, offer our current theoretical and engineering answer, and then place that answer back into the real world for continued testing.
SoulAuth is a beginning. It first tries to make the question of “who” precise, and then writes that answer into infrastructure.
