Security

Effective May 26, 2026.

Security on this site is two separate things in one place. There is comptrio.com, the marketing site, which is small, static-ish, and stores almost nothing. And there is FactoryOS, the product the site exists to introduce, where security is the design constraint that shapes the whole system. This page covers both, in that order.

The short version

Comptrio.com runs over HTTPS, sets no marketing cookies, stores no visitor accounts, and accepts only one kind of submission: the contact form. FactoryOS is designed so that customer data stays on customer infrastructure, no part of it is sent to a model vendor in the course of normal operation, and every agent reaches the smallest slice of data its job requires.

How comptrio.com is operated

The site is served over TLS, with HTTPS enforced and modern cipher configuration. Administrative access is held by the operator on hardware that is itself behind multi-factor authentication, and there are no customer accounts on this site at all. There is nothing for a visitor to log into, no shopping cart, no comment system, no third-party plugin ecosystem.

The only place where visitor-provided data enters the system is the contact form. Submissions are transmitted to the operator's inbox over authenticated mail transport and are not stored in any customer-facing database. Analytics for the site are aggregate and provided by Google Analytics 4, as described in the Privacy Policy. There are no marketing cookies, no advertising pixels, and no third-party social-media trackers loaded on any page.

Software for the site is patched on the ordinary cadence of its underlying components. Logs are reviewed when something looks unusual. Backups of the site's content are held off the server.

How FactoryOS is designed

The rest of this page is about the product, because that is where security actually lives for the people who care about it.

### Local-first by design

FactoryOS runs on hardware the customer controls. The model, the knowledge base, the agent runtime, and the data the agents act on all live on that hardware. Information needed to do a job does not have to be sent to a third-party model API in order for the system to reason about it, because the model is right there on the same machine.

That single architectural choice removes most of the threat surface that ordinary cloud AI introduces. There is no model-vendor copy of customer data, no per-request transmission to an external endpoint, and no dependence on a vendor's retention promises holding for as long as the data is sensitive.

### No silent data sharing

In normal operation FactoryOS does not call out to a model vendor. It does not telemetry-back to a SaaS, it does not phone home with usage data, and it does not stage customer documents in any cloud bucket as a side effect of doing its work. When the system reaches the public internet at all — to fetch an updated regulation, to look up an open piece of reference material, to crawl an authorized public site for the customer — it does so deliberately, under a configured policy, and never with the underlying private payload it was reasoning over.

### No customer data is used to train models

Nothing the customer puts into FactoryOS is used to train an AI model. Not mine, not a partner's, not a third-party vendor's. The model that runs inside a customer's deployment is the model the customer was given; it is not updated from that customer's traffic, it is not pooled with any other customer's data, and it is not sent anywhere for fine-tuning. Comptrio also does not rely on any third-party AI service to deliver FactoryOS — the reasoning happens on the customer's hardware, on a model the customer can keep.

### Least privilege as architecture

The knowledge base inside FactoryOS is split into channels by source and audience. Operations data, HR data, financial data, and regulatory data all live in different compartments, and access is granted one channel at a time. Most channels are closed by default, so a permission has to be deliberately granted rather than deliberately revoked. Roles set the broad shape of who can see what, and per-user overrides handle the exceptions.

The agents themselves run under the same rules as the people they assist. An agent that drafts a reply for one team cannot reach into another team's channel just because both are present in the system; the boundary is enforced by the structure, not by a policy reminder.

### Human approval where it matters

FactoryOS routes consequential actions through a human-in-the-loop step. Drafts are prepared, evidence is shown alongside the proposed action, and a person who is qualified to decide is the one who approves the send, file, or commit. The agent's job is to make that approval faster and better-informed, not to bypass it.

### Hosting models and tenancy

FactoryOS supports single-tenant deployments on customer premises, on customer-controlled colocated hardware, and on a customer-controlled cloud account. There is no shared-tenant SaaS pool where one customer's documents and another's are processed by the same running instance. A customer's deployment is, by construction, a single tenant.

### Logging and auditability

What the agents do is logged. Who saw what, who approved what, what the agent retrieved before it drafted — those are recorded and retained on the customer's own system at a retention policy the customer sets. Audit conversations begin with that log, not with vendor cooperation.

Limits and honest caveats

No system is unbreakable. A customer who runs FactoryOS on hardware they own is the one responsible for the physical security of that hardware, the operating system updates underneath it, the network it is reachable from, and the accounts of the people who use it. FactoryOS is designed to keep the data inside the customer's control; it cannot defend against an attacker who has already taken control of the customer's environment.

For the marketing site itself, the limits are conventional. The public internet is not a private channel, browser environments vary, third-party providers used by visitors have their own security postures, and no operator can promise that a site will remain available, unbroken, or free of bugs at every moment. The site is provided as-is, on the terms set out in the Terms of Use.

Vulnerability reporting

If you find a security issue with comptrio.com or with FactoryOS as delivered to a customer, please send the details through the contact form at the bottom of comptrio.com. Include enough information for me to reproduce or verify the issue. I will acknowledge legitimate reports promptly and will not pursue good-faith security research that follows the limits set out in the Terms of Use.

Changes to this page

This page may change as the site and product evolve. Material changes will be reflected in the effective date above.