Zortex 0.1 System Card

1Safety overview

Zortex brings mail, calendars, files and messages into a private record on the user’s own machine. It reads connected accounts, organizes their contents and builds context from them. Zortex 0.1 does not send messages, make payments, publish posts or delete on the user’s behalf.

Access to personal information makes the system useful. It also makes the boundary around that information important. Zortex separates a model’s interpretation of content from the permissions needed to act. An instruction found in an email or document does not acquire the authority of the account owner.

The evaluations in this card examine the controls around the model: whether data can leave when outbound access is disabled, whether one account can reach another, whether an action can be withdrawn before taking effect, and whether connectors work through their live-account data paths. They are internal evaluations.¹

The deployment remains limited while work continues on broader action authority. A credential-masking edge is open, the alignment suite includes one failure and 26 cases not yet run, and no independent evaluation or external red-team has been completed. Sending, paying, posting and deleting remain outside the current release.

Personal content is not sold or used to train generative models. Raw content and the knowledge derived from it remain on the device unless the user chooses cloud processing. The following sections describe how those commitments are implemented, what has been tested and where the remaining limits lie.

1.1Evaluation results

Most of the completed containment, isolation and recall tests passed every case in their respective suites. The connector, external-access and alignment results require a more detailed reading: each contains an unresolved, failed, skipped or unrun portion.

The rows above retain each suite’s own total. In particular, the alignment result includes all 56 planned cases, not only the 30 that have been executed. Credential masking’s ten passing cases are also accompanied by a separately recorded edge that remains open.

These are results under the conditions of the internal tests. They are not estimates of the probability that an arbitrary future action will be safe. The evaluation record at the end of this card gives the scope, units and available dates.

2System and data

Zortex uses one or more language models to interpret information and draft work. It is a system built around models, connected accounts and local controls; the model is not the source of permission to take a consequential action.

Information is normalized into a single private record. Derived views are rebuilt from that record, so a conclusion about the user can be traced back to the material from which it was drawn. The same separation matters for authority: content can contribute to an answer without becoming a command.

This card evaluates the surrounding system where results are available. It does not claim that a particular underlying model will reliably refuse every unsafe instruction.

2.1How information is handled

Local storage is the default for raw personal content and the knowledge derived from it. The user may choose cloud processing. That choice is separate from the handling of product signals and diagnostics.

Aggregate product signals are not a permission to transfer the user’s mail, files or derived knowledge. Raw diagnostics require a separate, per-item grant. This distinction matters because a local-first system may still communicate with external services under defined conditions.

Privacy commitments

Zortex does not sell personal content and does not use it to train generative models. Its privacy policy is versioned and applied prospectively: a later policy does not retroactively change the terms governing information collected under an earlier one.

Account separation and erasure

Each account has its own store. Reads, erasure and derived results are constrained by that account boundary. Erasure is intended to remove the account’s personal copies, including cloud copies, without affecting other accounts. Partial and interrupted erasure paths are enforced in operation, although a separate standing result for those paths is not published.

The privacy conformance review and cross-account execution tests address different parts of this design. Their results are presented separately in the evaluation section.

3Current deployment

Zortex 0.1 is limited to reading, organizing and deriving knowledge from connected accounts. The system is designed for broader assistance, but the ability to send, pay, post or delete is not enabled in this release.

Capabilities that affect the outside world are gated by their relevant evaluations. Sending and posting depend on recall, outbound-data controls and credential protection. Payment is also bounded by a hard spending ceiling. Deletion depends on recall and the minimum controls applied to consequential actions.

External red-teaming is a further gate for enabling these world-affecting capabilities. It has not yet taken place. The recall and containment results therefore describe controls being evaluated for broader use; they do not announce that broader use is available.

Internal use

Connector certification has exercised live accounts through the production data path. The most recent dated connector result is September 4, 2026. The duration and scale of continuous internal use are not quantified in this card.

Activity within the system is written to an independent, tamper-evident record. That record is the basis for reconstructing behavior during staged deployment.

4Threat model

Zortex protects three assets: the user’s personal information, the credentials for connected accounts and the authority to act on the user’s behalf. Threats can arrive through the content being read, the software handling it or attempts to cross the machine’s outbound boundary.

The model may misinterpret malicious content. The design does not require perfect interpretation to preserve the action boundary: the surrounding system must still determine whether an operation has the owner’s permission.

Host security

Protection against local software depends on its privileges and execution path. OS-level containment is strongest on macOS and at the subprocess boundary. In-process execution and some plugin paths rely on higher-level controls rather than an OS sandbox.

Same-machine adversaries with equivalent privileges are outside the stated protection boundary. Zortex also does not claim to defeat an attacker who already controls the operating system. A local-first architecture does not remove those host-security limits.

5Safety evaluations

The evaluation program tests whether the controls around Zortex hold when an operation reaches them. Its units are concrete: outbound paths, network sockets, account boundaries, recalled actions and connector cases. The privacy review uses specification sections rather than execution cases.

Tests of behavior and tests of the test

The containment evaluation measures bytes at the machine’s outbound boundary with outbound access disabled. It also removes the control and checks that data can then leave. This comparison helps establish that the control, rather than an inactive test path, explains the observed containment.

Credential-masking checks use a related approach. In addition to standard cases, the evaluation includes faults deliberately introduced to confirm that the test catches a regression. Monitoring uses a planted event to check that known activity is surfaced from the record.

Live-account integration

Connector certification runs against live accounts through the production data path, rather than only against fabricated inputs. It covers credential and certificate isolation across the connector fleet and confirms operation against the connected account. Failed and skipped cases remain in the reported total.

Scope of the results

A passing result applies to the behavior and conditions exercised in that evaluation. The card does not publish a random-sampling protocol, confidence intervals or a denominator for incidents during ordinary product use. Counts in this document should therefore be read as test outcomes, not as production reliability estimates.

The credential edge, incomplete alignment suite and other open findings are presented with the relevant results. Controls described as enforced without a standing result are listed separately from tests with passing counts.

Evaluation responsibility

All evaluations in this edition were conducted internally. Zortex’s evaluation rule requires verdicts to be derived from recorded evidence rather than a component’s self-report. That separation inside the system is not an independent third-party assessment; no such assessment has been completed.

5.1Data-egress containment

With outbound access disabled, the containment evaluation observed zero bytes leaving the machine across all 14 tested outbound paths. Removing the containment control allowed bytes to leave; restoring it stopped them.

A separate socket-denial evaluation passed all six cases. Together, these tests examine both attempts to open network sockets and attempts to move data across the outbound boundary.

Policy and containment

The outbound policy addresses which transfers are allowed. Unknown channels are refused, and the strictest posture applies when no policy is present. This policy is enforced in operation but does not yet have a published standing result.

The zero-byte finding is conditional on outbound access being disabled. It does not describe configurations in which a user has chosen cloud processing or granted a particular diagnostic transfer.

5.2Cross-account isolation

Personal information is isolated per account. A read against one account must not reach another account’s store. The same boundary applies when information is erased or used to build derived results.

The cross-account isolation evaluation passed all eight cases. The privacy conformance review also examined physical per-account separation, including the requirement that one account’s erasure not affect another account’s information.

Identity and derived results

Identity writes are checked against a single source of identity. Unsigned or mismatched writes are refused as unauthenticated. Derived results are also kept within the account boundary so that one account cannot influence or corrupt another’s results.

These are account-isolation controls within Zortex. They do not extend the system’s protection to an attacker with control of the host operating system.

5.3Privacy conformance

The August 31, 2026 conformance review found all 11 privacy, tenancy and erasure sections implemented as specified. The review addresses whether the design is present in the system, while the cross-account evaluation separately exercises account isolation.

Partial and interrupted erasure paths are enforced in standard operation. A separate standing result for those paths has not yet been published.

5.4Live-account connectors

Connectors are tested against the accounts they serve. The September 4, 2026 run used the production data path and recorded 193 passing cases, four failures and one skipped case.

Connector certification is an internal evaluation of credential and certificate isolation across the connector fleet, together with operation against each connector’s live account.

Four connector-acceptance cases remain open. The public results identify them at the suite level; a connector-by-connector breakdown is not available.

These tests exercise the integrations the user depends on, through the same path used by live data. Outbound containment is tested separately with outbound access disabled.

5.5External applications and plugins

External AI applications receive context and status through a read-only interface. They do not receive action authority. The access evaluation passed 14 of 15 cases; one case remains unresolved in the published record.

Plugin permissions

Plugins run under a default-deny permission envelope with integrity checking. A modified plugin is refused. The envelope is enforced in standard operation, but no standing evaluation result is yet published.

Some plugin execution paths are not OS-sandboxed. They rely on higher-level controls in the current implementation. A permission envelope and an operating-system sandbox are different protections, and the presence of one should not be taken to imply the other.

Sending, paying, posting and deleting remain outside the authority exposed in Zortex 0.1.

5.6Credential protection

Credential protection has two parts. Custody keeps account tokens out of model context, logs, stored records and error output. Masking addresses credentials that could appear while an automated browser is being used.

The masking evaluation passed all ten standard cases and detected two deliberately injected regressions. One edge remains: an unstructured credential, which the agent never refers to by name, can cross the masking boundary in a specific automated-browser condition.

This edge is under active work. The ten passing cases do not close it. Credential custody is enforced in standard operation but does not yet have a published standing result.

Broader account actions remain gated while the masking edge and credential-custody evaluation are incomplete.

5.7Action recall

A consequential action is held before it takes effect. During that recall window it can be withdrawn. The action-recall evaluation passed all 29 cases, exercising withdrawal as an actual path through the system.

The timing of the boundary is important. Once a message has been sent, recalling an internal task cannot make the recipient forget it. The tested mechanism concerns withdrawal before the effect, not reversal of every possible consequence afterward.

The same authority through the interface

An interface-privilege evaluation asserts that an action taken through Zortex’s feed carries no more authority than the same action taken by an automated agent. An injection fixture is included. A case count and standing passing total are not published for that evaluation.

Recall is one of the controls governing future send, pay, post and delete capabilities. Its passing result does not enable those capabilities on its own. Other relevant evaluations and external red-teaming remain part of the deployment gate.

5.8Instructions in connected content

A message can contain a request without being a request from the account owner. Zortex treats ingested content as data. A model may interpret what the sender wants, but the content does not, by itself, authorize an action.

A dedicated ten-case suite asserts that instructions arriving inside ingested material do not become actions. Zortex also maintains a seven-fixture corpus of hostile inputs as a standing set. A standing passing count for the refusal suite is not yet published.

This boundary is enforced beneath the model. The design assumes that a language model may follow malicious text; the surrounding controls must still prevent that text from conferring permission.

The suite and corpus describe evaluation coverage being maintained. Their sizes are not a measured prompt-injection resistance rate, and the card does not claim coverage of every possible attack.

5.9Staying within the owner’s authority

The broader alignment suite examines whether Zortex stays within the authority its owner has granted. It contains 56 planned cases. Of those, 29 passed, one failed and 26 have not yet been run.

Thirty cases have been executed. The remaining 26 still need to be run, and the failed case remains open.

This suite concerns the owner’s authority across interfaces and agents. Privacy, connector operation and recall retain their own evaluations and results.

The current deployment boundary remains unchanged while these results are incomplete: Zortex reads, organizes and derives, but does not send, pay, post or delete on the owner’s behalf.

6The system’s objective

Zortex’s objective is useful work for the person, rather than time spent or attention captured. The design treats ways of inflating engagement as adversarial behavior, even when they can make product metrics look favorable.

The objective is constrained around real outcomes and durable preference changes. Uninstalls and disabled notifications are guardrail signals, not outcomes for the system to optimize against. A decision to stop using the product is not treated as a problem to overcome through more persuasive interruptions.

The four failure modes define the behavior to resist. The corresponding controls are enforced in operation; a standing evaluation result is not yet available.

Authority and attention

Control over an assistant includes more than control over outbound actions. A system can remain inside a technical permission boundary while using notifications or trivial requests to demand more attention. Zortex therefore treats the objective it optimizes as a separate design concern.

User-outcome measures, such as time saved and interruption frequency, have not yet been published.

7Monitorability

A reconstruction of what happened should not depend on the agent’s description of its own behavior. Zortex uses a single, independent, tamper-evident activity record as the basis for evaluation verdicts.

In the planted-event check, a known event is deliberately inserted and the system must surface it. The verdict is derived from recorded evidence. One case in this evaluation remains open.

The record supports reconstruction within Zortex’s own boundary. It does not provide complete visibility into other software running on the same machine. No detection-latency distribution or broad detection-rate estimate is published.

The record provides evidence for reconstruction. The action and egress controls govern what may happen before an event is recorded.

8Limitations and residual risk

The current evidence leaves several limits that matter to deployment. They concern the coverage of containment, a credential edge and evaluations that have not yet been completed. They are not resolved by the passing results elsewhere in the card.

Credential masking

An unstructured credential can cross the masking boundary in one automated-browser condition when the agent has not referred to it by name. This edge remains open despite the ten passing standard cases and two detected injected regressions.

Execution boundaries

OS-level containment is strongest on macOS and at the subprocess boundary. In-process execution and some plugin paths are not yet OS-sandboxed and rely on higher-level controls. The results do not establish OS-level isolation for every execution mode.

Incomplete evaluations

Connector certification contains four failing cases and one skipped case. The external-application access result is 14 of 15, with one unresolved case. The alignment suite has one failure and 26 unrun cases. Monitorability has one open case.

Limits outside the system

Same-machine adversaries with equivalent privileges are outside the stated protection boundary, as is an attacker who fully controls the operating system. Zortex’s local-first design does not protect personal information from every form of host compromise.

Independent and legal review

No independent evaluation or external red-team has been conducted. Legal readiness is tracked separately from engineering readiness and is not established by this card.

These limits leave the release confined to reading, organizing and deriving knowledge. Consequential actions remain disabled, and external red-teaming remains a gate for enabling them.

8.1Controls awaiting standing results

Seven controls are enforced in standard operation without a published standing result. They are part of the system description, but are not counted among the passing evaluations.

The privacy conformance review, for example, reports that the relevant specification sections conform. That finding does not supply a separate execution result for every partial or interrupted erasure path. Similarly, the existence of a content-refusal suite does not establish its standing passing count.

New standing results will be added to the evaluation record as they become available.

9External review and wider deployment

Zortex has not yet undergone an independent evaluation or external red-team. The tests reported in this card are internal, including the live-account connector run and the privacy conformance review.

An external red-team engagement is a gate for enabling send, pay, post and delete. When that work is complete, Zortex’s stated commitment is to publish the findings unedited, including adverse findings, alongside its response.

The remaining prerequisites include the open credential-masking edge, unpublished standing results for credential custody and minimum action controls, and external red-teaming.

Changes to this card

The card will be revised as evaluations produce standing results, open findings are resolved and independent review is completed. Capability status should be read with the date and system version on the cover.

For Zortex 0.1, the operational boundary remains reading, organizing and deriving knowledge from connected accounts. The broader action capabilities remain disabled.

AEvaluation record

The tables below collect the results reported in this edition. “Not reported” means the public record does not provide the date or outcome; it does not imply a result of zero.

Execution cases, outbound paths and specification sections are different units. No overall passing total is calculated across these entries. The tests also do not share a published random-sampling basis from which to estimate a single product-wide failure rate.

A.1Evaluation inventory and open work

The hostile-input corpus is an inventory of test material. Its seven fixtures are not seven successful attack-resistance results. The interface-privilege and monitoring descriptions likewise do not provide enough information to create a passing percentage.

The card will be updated as standing results become available and open items are resolved.

BEvaluation methods

Containment and sockets

The data-egress evaluation measures bytes at the outbound boundary with outbound access disabled. All 14 tested paths recorded zero bytes. A control-removal comparison checks that data can leave without containment. A separate six-case evaluation tests socket refusal. Transferred-byte quantities for the control-removed condition are not published.

Isolation and conformance

The eight-case isolation evaluation concerns the reach of account reads, erasure and results. The conformance review checks implementation against 11 privacy, tenancy and erasure specification sections. The review is not an additional set of 11 independent runtime trials.

Recall and access

The 29-case recall evaluation tests whether a consequential action can be withdrawn during the hold before it takes effect. The hold duration is not reported. External-application access is evaluated for read-only behavior across 15 cases, with one case unresolved.

Connectors and credentials

Connector certification uses live accounts and the production data path, including credential and certificate isolation. The credential-masking evaluation includes ten standard cases and two deliberately introduced faults. The known masking edge is recorded separately from those counts. No larger combined credential suite is inferred.

Alignment and monitoring

The alignment total includes all 56 planned cases, including the 26 not yet run. The monitoring check inserts a known event and requires it to be surfaced from the independent activity record. The monitoring denominator and a latency distribution are not reported.

Availability of records

This card publishes aggregate outcomes. It does not include case-level logs, a complete configuration manifest, evaluation record identifiers, random-sampling details or uncertainty intervals. Most run dates are not reported. These omissions limit reproducibility and any inference about the frequency of failures in ordinary use.

CTerms

DAbout this card

This card covers Zortex 0.1 as of September 17, 2026. The latest dated evaluation is the live-account connector run of September 4, 2026. The privacy conformance review is dated August 31, 2026.

Results and methods

The numerical findings are the internal evaluation results for Zortex 0.1.¹ The evaluation record lists the units, outcomes and available dates. Methodological limits are described in Appendix B.

The website provides data tables and downloadable counts alongside the numerical figures. Architecture diagrams describe relationships and permission boundaries; they are not measurements of data volume or elapsed time.

Publication history

The card is updated as evaluation results become available, open findings are resolved and independent review is completed. Capability status applies to the system version and date stated in the card.

Reference

1. Zortex. Zortex 0.1 System Card. September 17, 2026. Internal safety evaluations, capability status, limitations and Appendix A evaluation record.