Security Architecture

    Confidential by default. Independently verifiable. Designed to minimise raw data exposure.

    Overview

    NexArt is verifiable execution infrastructure for AI and software systems. Security is enforced at the execution and proof layers, not added as an afterthought.

    NexArt produces tamper-evident, independently verifiable execution records. In confidential mode, raw AI inputs and outputs are not stored in permanent proof records by default; records use hash-bound commitments and the metadata needed for verification. NexArt stores the cryptographic and operational data needed to verify, operate, secure, and bill the service.

    Customer configuration affects what is processed and retained. Full-content mode, if explicitly enabled, changes the data-exposure profile and must be assessed separately.

    Execution Architecture

    How execution inputs, sandboxed execution, artifact output and verification metadata relate across the certification boundary.

    Execution InputsParameters + seed valuesExecution payload (ephemeral)Context signals+ metadataSandboxed Execution(Isolated Environment)Pinned runtime + protocol versionNo network / no filesystemEphemeral container(destroyed after run)Execution Output(Deterministic Artifact)Binary output artifactReturned to client,not stored by NexArtCertificationBoundaryVerification MetadataOutput hash, runtime hash,protocol versionUsage event metadata(no payload stored)CER returned to client(client-retained, not stored by NexArt)NexArt stores proof metadata only.Execution payloads and artifacts are never retained.
    Legend|Solid arrows indicate execution flow|Dashed boundary indicates the certification and metering boundary

    Execution and proof boundary

    NexArt separates execution from proof storage. The execution path produces an output that is returned to the client. The proof path produces a Certified Execution Record that captures cryptographic commitments, signatures, and the metadata required for independent verification.

    • Raw input and output are rejected in confidential attestation paths by default.
    • Failed ingest paths apply redaction before any persistence.
    • Public verification responses are restricted to fields required to confirm integrity.

    Confidential mode

    Confidential mode is the default profile for AI execution records on the Canonical Node.

    • Raw AI prompts, inputs, and outputs are replaced with hash-bound commitments before permanent proof storage.
    • Confidential attestation paths reject submissions containing raw AI input or output.
    • Verification can be performed against the commitments without exposing the underlying content.

    Full-content mode, if explicitly enabled by a customer, allows raw content to be processed and retained according to the applicable configuration and retention policy. This mode carries a higher data-exposure profile and must be assessed separately.

    Key and signature model

    • Each attestation node holds its own signing key.
    • Node public keys are published at a well-known URL for independent retrieval.
    • Signatures are issued over canonicalised record fields per the protocol specification.
    • Node deployment secrets are held in an admin-only secrets store with access restricted to operational roles.
    • Node signing keys are rotated on a defined schedule and immediately upon any suspected compromise. Verification relies on published public keys, so rotation does not affect verification of previously issued receipts.

    Public verifier model

    The public verifier at verify.nexart.io is designed for minimum disclosure.

    • Exact-hash lookup only. No browsing, listing, or enumeration of records.
    • Strict input validation on certificate hash and execution identifier.
    • Hidden or deleted project bundles are suppressed from public lookup.
    • Raw prompts, inputs, outputs, account emails, API keys, and internal operational metadata are not exposed by default.

    Data retention boundaries

    The lists below describe the default confidential-mode profile. Customer configuration, mode selection, and the applicable agreement can change what is stored.

    Not stored by default in confidential mode

    • Raw AI prompts.
    • Raw AI inputs.
    • Raw AI outputs.
    • Secrets or credentials contained inside execution content.
    • Raw IP addresses in application logs by default.

    Stored or retained where needed

    • Certificate hashes and proof metadata.
    • Signatures and timestamps.
    • Protocol version and runtime hash.
    • Lifecycle and visibility state for proof records.
    • Account identifiers.
    • Hashed API keys (raw keys are never stored and never recoverable).
    • Billing and subscription identifiers (via the payment processor).
    • Pseudonymised IP and security logs.
    • Usage events.
    • Compliance and operational records.

    Access controls

    • API keys are hashed at rest. Raw keys are never stored and never recoverable.
    • Keys are scoped to accounts; quota enforcement happens before execution begins.
    • Revoked keys are rejected before execution.
    • Internal Ops governance modules (sub-processors, incidents, access reviews, DSAR register, compliance library) are admin- and ops-only.
    • Access review records are maintained on a recurring cadence.

    Access control responses:

    • 401 Unauthorized: invalid or revoked API key.
    • 429 Too Many Requests: account quota exceeded.

    IP minimisation

    Application logs do not retain raw client IP addresses by default. IPs are processed through a salted derivation (IP_LOG_SALT) so that security investigations remain possible without persisting the underlying address. A LOG_RAW_IPS escape exists strictly as an explicit debug control and is not enabled in normal operation.

    Retention enforcement

    The Canonical Node enforces retention windows for proof records according to the applicable retention policy. Legal-hold flags suspend deletion for records under regulatory or contractual hold. See the CER retention policy for the current rules.

    Incident and access governance

    • Incident register: security and availability events are recorded with classification, timeline, and follow-up actions.
    • Access review register: periodic reviews of internal access to production and Ops systems.
    • Sub-processor and transfer register: list of sub-processors and international data flows.
    • DSAR register: receipt, triage, and response to data-subject requests.
    • Compliance library: internal policies and supporting documents, available under NDA where appropriate.

    These records support audit and evidence-review workflows. They do not by themselves constitute a compliance certification.

    Threat model

    NexArt is designed to defend against:

    • Tampering with proof records after the fact.
    • Replay or forgery of execution claims.
    • Unauthorised API key usage and quota bypass.
    • Unintended exposure of raw AI prompts, inputs, or outputs in confidential proof paths.
    • Unintended exposure of internal operational metadata via public surfaces.
    • Enumeration of records via the public verifier.

    Limitations

    • NexArt does not currently hold SOC 2, ISO 27001, or ISO 42001 certification.
    • Some compliance documents require legal review before external reliance.
    • NexArt verifies integrity. It does not verify output correctness, fairness, lawfulness, or model quality.
    • Full-content mode, if explicitly enabled, carries higher data exposure than confidential mode.
    • Customer configuration and integration choices affect what NexArt processes and retains.

    What NexArt does not do

    • NexArt does not perform business-logic validation or correctness checking.
    • NexArt does not act as a general compute or AI inference platform.
    • NexArt does not replace financial audits or regulatory compliance reviews.
    • NexArt does not certify that AI outputs are fair, unbiased, or lawful.

    NexArt certifies execution integrity, not correctness or intent.

    Related