Bind verified identity to your AI execution records.

An identity association you can review later

Your application verifies a user's identity through its identity provider, constructs a minimal identity reference, and includes it in the execution snapshot before sealing. A Certified Execution Record (CER) protects that association alongside its other protected execution evidence.

This answers two specific questions: which identity did the application associate with this recorded execution, and has that association changed since the record was sealed? It does not independently establish who the person is or whether they personally performed every recorded action.

• Associate a recorded execution with an identity verified by your application.
• Detect changes to the recorded identity association.
• Avoid including raw login tokens, names or email addresses in the identity object.
• Preserve the sealed identity association when submitting the complete CER for node attestation.
• Keep identity optional for workflows that do not require an identity-bound record.

The application is the identity authority

The integrating application authenticates the account through its identity provider and decides which assertion belongs to the request. NexArt does not replace that identity provider or make an independent authentication decision.

A recorded verified status is the application's assertion that authentication succeeded. It is not a NexArt identity certificate. An assertion commitment lets a reviewer check correspondence with the assertion bytes they hold; a hash alone does not authenticate the assertion's issuer.

A subject reference identifies an account in its issuer's scope. It is not, by itself, a legal identity or proof of personal participation. Account association must respect the application's privacy policy and any delegated or service-account behavior.

What integrity verification and node attestation establish

SDK integrity verification checks the recorded artifact and applicable protocol rules. Node attestation adds a signed receipt for the submitted record. Neither process contacts the identity provider to authenticate the user or validates the original login token.

The protected association is evidence of what the application recorded. It does not prove model execution, output correctness, capture completeness, or that a particular human personally initiated the model call. Stronger attribution depends on the application's authentication, request-binding and authorization evidence.

Submitting the complete CER retains the identity association within the protected record. This describes its evidence scope, not a claim that every integration's node retrieval or export path has been tested.

Minimal identity data, not automatic anonymity

Use minimal references and assertion commitments rather than raw login tokens, names or email addresses in the identity object. This reduces what is included there; it does not guarantee that the rest of the CER contains no personal data.

Hashed identifiers are not automatically anonymous. Linkability, predictable identifiers and access to other records can still make a person identifiable. Retention, disclosure and data-protection decisions remain the application's responsibility.

Identity is optional at the SDK layer. A CER without identity can still pass integrity verification. Your application can require identity for selected workflows through its own policy.

One association per recorded execution

Attach the appropriate identity to each execution that requires it. Grouping or chaining records does not automatically transfer identity to later steps and is not another authentication process. Project Bundles can surface an embedded execution's identity in their step registry.

Adding or changing hash-bound identity after sealing requires a new seal and, where required, a new node attestation. The previous attestation must not be presented as covering the modified record.

The public identity-binding demos use self-asserted identifiers rather than an identity-provider login. They show an association with evidence, not an application-verified identity flow.