A Valid Credential Can Still Identify the Wrong Agent

TL;DR for operators

An AI agent can authenticate successfully while its credential, software client, or external identity record is associated with the wrong persistent actor. This becomes consequential when agents operate across deployments, rotate credentials, and accumulate audit histories.

SoulAuth proposes a stable ActorIdentity for each independently identifiable Human or long-lived AI actor. Credentials, clients, sessions, and cross-domain identity relationships remain separate objects with their own lifecycles. Authentication proves an identity under specified conditions; it does not automatically establish permission to act.

The authors translate this architecture into ten invariants and test them against a Rust reference implementation.¹ SoulAuth v0.1.0 passes 188 unit tests, 61 active conformance checks, and 355 integration assertions, but nine conformance checks remain unsatisfied. For enterprise architects, the proposal offers a concrete basis for agent identity governance, with important implementation gaps still unresolved.

Authentication Can Succeed While Attribution Fails

Consider an enterprise AI agent that operates for several months. It changes deployment environments, rotates its authentication keys, and interacts with applications through different protocol clients. Each application may correctly verify the credentials presented to it.

The organization still needs to establish whether activities performed before and after those changes belong to the same agent.

Successful credential verification does not necessarily resolve that question. A valid credential might be associated with the wrong identity record. A registered software client might be mistaken for the actor operating through it. Two records from different identity systems might be incorrectly treated as equivalent because their identifiers resemble one another.

These are the identity-misattribution failures examined in SoulAuth’s security analysis. The concern is not necessarily that cryptographic verification fails. It is that otherwise valid evidence can be assigned to the wrong persistent subject.

For enterprises, the consequences extend beyond login correctness. Incorrect attribution can undermine audit records, credential ownership, and the identity facts used by downstream access-control systems.

ActorIdentity Separates the Persistent Subject From Its Credentials

SoulAuth’s principal architectural decision is to establish ActorIdentity as the canonical continuity boundary.

An ActorIdentity represents the persistent subject within SoulAuth’s identity domain. Its ActorKind can be Human or AIActor. Both receive first-class identity-subject status, without requiring identical authentication methods or making an AI actor dependent on a human account.

First-class status is an engineering property. It does not imply consciousness, legal personhood, or equal authority.

The surrounding objects serve different purposes:

Source: SoulAuth, Section 3.4. These are intended architectural semantics, not a claim that every lifecycle requirement is fully implemented.

The distinction matters because an enterprise agent’s operational components may be replaced repeatedly without creating a new accountable subject.

The authors formulate ten canonical invariants around this principle. The first four separate ActorIdentity from HumanAccount, Credential, Client, and IdentityBinding. Two others require credential rotation and client changes to preserve the actor’s identity. The remaining requirements establish Human–AIActor identity parity, separate Authentication from Authority, protect historical attribution, and prohibit reassignment of retired ActorIdentity identifiers.

The model is deliberately domain-specific: ActorIdentity is canonical within SoulAuth, not a globally authoritative identifier across unrelated systems.

Identity Continuity Does Not Preserve Authentication Trust

Keeping an actor’s identity stable does not mean preserving every authentication result associated with it.

A credential might be revoked while the ActorIdentity remains valid. A session might expire without changing the underlying subject. Runtime migration might require fresh authentication because the trust context has changed.

SoulAuth separates three questions:

This separation also governs identity relationships across systems.

When an enterprise identity provider and SoulAuth maintain distinct identity records, an explicit IdentityBinding can represent their relationship. Matching email addresses or external subject identifiers do not automatically establish equivalence. Revoking a binding should terminate the relevant relationship without rewriting either identity or its prior history.

Historical attribution imposes an additional requirement: an authentication event must remain associated with the ActorIdentity identified when the event occurred. Later credential rotations, account changes, or binding updates must not retrospectively alter that record.

These properties address different failure conditions. Persistent identity supports continuity; current authentication evidence supports trust; authorization policies determine permitted actions.

An authenticated agent therefore has no automatic entitlement to execute a payment, modify customer records, or delegate access.

Architecture Conformance Tests What Functional Success Cannot

The paper develops a methodological chain from conceptual identity definitions to implementation verification.

Its Philosophical Engineering approach begins by defining what should count as a persistent identity subject. The resulting ontology, invariants, and lifecycle rules are then reflected in a logical architecture separating identity management, authentication, sessions, protocol projection, security protections, audit, and persistence.

These are logical responsibilities, not necessarily separate deployed services.

The authors subsequently introduce Architecture Conformance to evaluate whether the implementation actually preserves the proposed relationships.

An authentication endpoint passing a functional test establishes that some expected operation succeeded. It does not necessarily establish that credentials have independent lifecycles, protocol clients are distinct from actors, or historical records retain stable attribution.

Architecture Conformance therefore examines schemas, implementation objects, runtime behavior, machine-readable contracts, lifecycle transitions, and negative test cases. Its verification targets are architectural properties, not just successful API responses.

The Rust implementation demonstrates partial conformance

The evaluation examines SoulAuth v0.1.0, released September 9, 2026, at the fixed Git revision aaad1abc52c8ab53c2a911f92e2698df95b0a17b.

The reported verification results are:

• 188 passing unit tests.
• 61 passing active architecture conformance checks.
• 355 passing integration assertions.
• Nine additional conformance checks remaining unsatisfied.

The six summarized architectural properties have the following statuses:

Source: SoulAuth, Section 7.3. These are conformance observations for one fixed release.

The two partial results directly concern the architecture’s central promise.

AIActor key lifecycles are represented independently, but Human-side Credentials have not converged on the intended unified lifecycle model. Some historical audit events also continue to reference Human-oriented user_id fields rather than consistently anchoring attribution to ActorIdentity.

The conformance results are the paper’s main implementation evidence, while lifecycle and negative tests provide claim-specific verification. The identity-misattribution scenarios are threat-model analyses, not measured attack-success experiments.

The distinction is material: passing hundreds of checks demonstrates that tested behaviors worked, while the unsatisfied checks identify architectural requirements the implementation has not yet fulfilled.

Enterprise Adoption Requires Stable Identity and Separate Decision Rights

For organizations operating long-lived AI agents, SoulAuth suggests several concrete architectural decisions.

Agent onboarding. Identity architects can assign a persistent identity to an independently accountable agent before associating it with execution workloads, protocol clients, and credentials. This is relevant when the organization expects an agent to persist across deployments. Short-lived AI-enabled processes do not necessarily require independent AIActor identities.

Credential operations. Security teams can design rotation and revocation procedures around an unchanged actor identity. Rotation should update authentication capabilities without erasing accountability, while revoked credentials and expired sessions must cease providing trust under the applicable rules.

Audit integrity. Compliance and platform teams can require historical authentication events to preserve their original actor attribution. This becomes particularly significant when an agent changes clients, infrastructure, or external identity bindings.

Authorization and governance. Application owners can consume verified identity facts without treating those facts as permission grants. Execution eligibility, transaction limits, delegation, and approval requirements remain decisions for downstream systems.

Platform evaluation. Procurement and architecture teams can ask vendors to demonstrate credential ownership, actor continuity, cross-domain mapping, revocation behavior, and historical attribution through specific tests. Basic support for OAuth/OIDC or successful login flows is not sufficient evidence for these properties.

These are Cognaptus interpretations of the proposed architecture, not measured enterprise deployment outcomes.

The approach is also complementary to existing infrastructure. OAuth/OIDC provides protocol mechanisms; SPIFFE and WIMSE address workload identity; other persistent-agent architectures may address memory, code, or behavioral continuity. SoulAuth specifically concentrates on identity-subject continuity and authentication.

What the Fixed Release Does Not Establish

SoulAuth provides an inspectable architectural proposal and a runnable reference implementation. Its evaluation does not establish complete architectural conformance.

The two partially realized properties are particularly relevant to enterprises that require consistent credential governance and durable audit attribution. They should be treated as unresolved implementation requirements, not automatically available capabilities.

The paper also reports no comparative security effectiveness, production-scale performance, longitudinal reliability, or deployment outcomes across multiple enterprise environments. Its threat analysis assumes foundational trust in the core runtime, canonical persistent state, and underlying cryptographic mechanisms.

Passing conformance tests therefore cannot be interpreted as comprehensive security certification or proof that SoulAuth outperforms alternative identity systems.

Identity Is a Foundation for Accountability, Not a Grant of Authority

SoulAuth identifies a specific architectural weakness in persistent agent infrastructure: valid authentication evidence can be associated with the wrong enduring subject.

Its proposed remedy is a canonical identity record whose continuity does not depend on credentials, clients, sessions, or execution environments. The ten invariants make that distinction explicit, and Architecture Conformance provides a way to inspect its realization.

The fixed implementation demonstrates that several central boundaries can be made executable. Its incomplete credential modeling and historical attribution also show where architectural intent has yet to become consistent system behavior.

For enterprise AI architects, the central design question is whether identity infrastructure can reliably establish which persistent actor is being authenticated, preserve that attribution over time, and leave permission to act to an explicitly separate authority system.

Stable identity makes accountability possible. It does not establish trustworthy authentication on its own, and it does not determine what an agent should be allowed to do.

Cognaptus: Automate the Present, Incubate the Future.