Trust and security Incomplete
Autom is pre-release. This page separates the controls that are implemented and checkable today from the questions that have not been answered. Unanswered items are marked, not padded out.
This page is incomplete on purpose. Everything described as implemented can be verified in the source of this website. Everything else is shown as a token in double square brackets, because a security page that guesses is worse than one that admits a gap. No certification, audit, or independent assessment is claimed anywhere on it.
Each control below exists in the source of this website. You can confirm most of them yourself by looking at the response headers this page was served with.
Every response from this site carries nosniff, a strict referrer policy, and a same-origin resource policy. Document responses add frame denial, an opener policy, DNS prefetch off, a permissions policy, and a content security policy.
Sent on every request that arrives over TLS, with a two-year max-age and subdomains included. The preload directive is deliberately not sent: it is a one-way door that would pin every subdomain to HTTPS in shipped browsers for two years, and we have not submitted to the preload list. It is withheld entirely on plain HTTP so local development cannot poison a browser's HSTS cache.
No directive names any host other than this site's own origin. Script and style sources additionally allow inline content, because the framework requires it to hydrate, and images and fonts additionally allow inline data URIs. This is described in full below rather than glossed over.
There is no analytics script, no advertising script, no tag manager, and no session recording on this site. The configuration field reserved for an analytics identifier is empty and nothing reads it.
The database schema in this repository is deliberately empty. This site defines no table and stores no visitor record, no session, and no submitted enquiry.
The vulnerability disclosure policy below is the published reporting channel. An RFC 9116 security.txt file is prepared but is deliberately not published yet: it would name a contact mailbox that has not been provisioned, and a disclosure address that routes nowhere is worse than none at all. It goes live with the mailbox.
Copied from the two files that set them, so you can diff this table against a real response rather than trust a summary of it.
The controls in this group are implemented in the source of this site and can be checked from outside by inspecting a response.
Two kinds of statement appear below. The first describes a control that exists in the code of this website. The second is a question we have not answered, shown as a token in double square brackets.
A token means the fact has not been established or confirmed. It does not mean a value exists and is being withheld from you.
Where the honest answer is that something does not exist yet, this page says that instead of using a token. A pre-release product with no certifications is a normal position. Pretending otherwise is not.
This site is served from a Cloudflare Worker. Every document response passes through a single module that applies the security headers listed below, and that module is the only place those headers are set in production.
Static files are served by the platform's asset layer before the Worker runs, so they never reach that module. They are covered separately by a headers file in the repository, which repeats nosniff, the referrer policy, the resource policy, and HSTS.
HSTS is sent only when the request arrived over TLS. On plain HTTP it is withheld deliberately, so a developer running the site locally cannot pin an HSTS entry against localhost for every other project on the machine.
Naming the runtime here is a statement about this website's own code. It is not a published sub-processor list. That list is at [[SUBPROCESSOR_LIST]], and the infrastructure behind the Autom product is a separate question, at [[PRODUCT_INFRASTRUCTURE]].
The full policy is in the table above. No directive names any host other than this site's own origin, framing is denied outright, plugin content is blocked, and insecure requests are upgraded.
The script source allows inline scripts. This is a real weakness and we are not going to hide it in a footnote. The App Router hydrates the page by emitting inline bootstrap scripts, and without that allowance the site renders as a dead shell. The policy therefore does not prevent an injected inline script from running, and it should not be described as if it did.
The intended fix is a per-request nonce combined with strict-dynamic. That needs middleware which does not exist in this repository yet. It is recorded in the source as a to-do, not as a completed control.
The style source allows inline styles for the same class of reason: the UI framework and the CSS toolchain both emit inline style attributes.
Everything else stays at same-origin because it can. The site loads no third-party script, font, stylesheet, iframe, or embed, and makes no request to another host. The only sources named beyond this site's own origin are the data URI scheme on images and fonts, and blob URIs on images, both of which are inline content rather than another party.
This website runs no analytics, no advertising, and no tracking. There is no tag manager, no pixel, and no session recording.
The site's content file has a field reserved for an analytics identifier. It is set to null, and no component reads it. We checked that before writing this sentence rather than assuming it.
The site sets no cookie of its own and does not use local or session storage to identify a visitor. Any cookie set by hosting or edge protection infrastructure is a separate matter and belongs at [[COOKIE_TABLE]].
This is enforced rather than merely promised: the content security policy restricts connections to same-origin, so a browser will refuse an outbound request to a tracking host even if one were added by mistake.
The form is the only thing on this site that sends what you type to the server. Submissions are validated on the server, with a minimum and a maximum length on every free-text field, a fixed list of accepted values for company size, and a cap on the size of the request body that is applied while the body is still arriving rather than after it has been read.
The same validation rules run in the browser before the request is made, from the same module, so the messages you see and the messages the server would give you cannot drift apart. The server stays authoritative: whatever it returns is what the page shows you.
Accepted submissions are forwarded to a webhook destination held as a platform secret. If no destination is configured the endpoint returns an error and says plainly that nothing was sent, rather than accepting the message and discarding it. It never invents a fallback email address: the failure message offers another channel only when one has actually been configured.
There is one deliberate exception to that, and we would rather state it than let you find it. The form carries a hidden decoy field that no person sees and that automated form-fillers routinely populate. A submission that fills it is discarded and answered as though it had succeeded, so that a bot cannot learn which field is the trap by comparing responses. That is a spam control, and the cost of it is real: if some unusual client fills that field on your behalf, your enquiry will be dropped and you will be told it was sent. Nothing else on this site answers success for a message it did not deliver.
The decoy value is never forwarded anywhere and is not part of the payload a destination receives.
This website has no database. The schema file in the repository is deliberately empty, so no enquiry is stored here.
The endpoint counts requests per client, but that counter lives in the memory of one edge isolate. It is a speed bump against a double-click or a naive script, not a rate limit, and a distributed caller defeats it. The source says exactly that, and so do we.
Where enquiries are delivered, and how long they are kept, is at [[CONTACT_FORM_DESTINATION]] and [[ENQUIRY_RETENTION_PERIOD]].
Autom is pre-release and downloads are not open. The controls below describe the product rather than this website, and most of them are not settled.
This is the section that matters most to a reviewer, so it is not buried at the bottom of the page.
Autom works by sending business content to a language model. When a customer gives an AI teammate a task, the description of the company, the instructions for that task, and the material the task needs are transmitted to the model the customer selected. Those models are operated by third parties. We do not operate them.
Any organisation evaluating Autom should treat that as the central question. Business content leaves the customer's machine and reaches a third party by design, not by accident.
Which providers can receive that content is at [[MODEL_PROVIDERS]]. What each of them retains, and for how long, is at [[MODEL_PROVIDER_RETENTION]]. Whether content may be used to train a provider's models is at [[MODEL_TRAINING_POSITION]], and it has to be answered provider by provider. Do not assume the answer is no.
Whether an organisation can restrict which models its teams are allowed to select is at [[MODEL_SELECTION_CONTROLS]].
Model output is generated text. It can be wrong, incomplete, or invented. Human approval in Autom is optional and configurable: a customer can require a person to approve, decline, or ask for another attempt before an action runs, or can switch that off for a task. Switching it off means work executes without a person checking it first. That choice belongs to the customer, and so does its consequence.
A customer describes its business in ordinary language, and Autom builds departments, AI teammates, tasks, and approval decisions from that description. All of it is customer content, and the customer decides what goes into it, including whether it contains information about identifiable people.
How one customer's workspace is kept separate from another's is at [[TENANT_ISOLATION_MODEL]].
Encryption in transit and at rest for product data is at [[ENCRYPTION_IN_TRANSIT]] and [[ENCRYPTION_AT_REST]]. We are not going to name a cipher, a key length, or a key management approach that has not been confirmed.
Where product data is stored, and whether a customer can choose a region, is at [[DATA_RESIDENCY_OPTIONS]].
Retention and deletion follow the Privacy Policy: customer content is kept for [[CUSTOMER_CONTENT_RETENTION_PERIOD]] after an account closes, and backups follow their own cycle at [[BACKUP_RETENTION_PERIOD]].
What the desktop application reports back is at [[TELEMETRY_DESCRIPTION]]. That is not settled, and we will not describe it until it is. Signing and checksum verification for official builds is at [[CODE_SIGNING_DETAILS]] and will be published with the first release.
Autom gives a company a shared workspace, so who is inside it matters. Membership is controlled by the customer, and the customer is responsible for who it invites.
Sign-in methods, whether multi-factor authentication is supported, and whether single sign-on is available are at [[AUTHENTICATION_METHODS]].
The roles and permissions available inside a workspace are at [[WORKSPACE_ROLE_MODEL]].
Autom is a desktop application, so part of access control sits on the customer's side: device patching, disk encryption, screen locking, and controlling who can sign in on a given machine.
Whether Neoteric staff can reach customer content, under what approval, and whether that access is logged, is at [[INTERNAL_ACCESS_CONTROLS]]. Every reviewer should ask this, and there is no published answer yet.
Security training for staff is at [[EMPLOYEE_SECURITY_TRAINING]]. Background screening is at [[BACKGROUND_CHECK_POLICY]].
Neither is described here, because neither has been confirmed. A page that claimed annual training and screened staff without evidence would be the easiest thing on this site to disprove.
This website runs on an edge worker runtime with static assets served from the platform's asset layer. Both paths are covered by the headers described above.
The infrastructure behind the Autom product, including its providers and regions, is at [[PRODUCT_INFRASTRUCTURE]].
Environment separation, change control, and who is able to deploy are at [[CHANGE_MANAGEMENT_PROCESS]].
Logging, monitoring, and alerting are at [[LOGGING_AND_MONITORING]].
How security updates to third-party dependencies are tracked and applied is at [[DEPENDENCY_PATCHING_PROCESS]].
No penetration test has been carried out, and none is claimed on this page.
Any testing programme, its scope, and its frequency will be described at [[PENETRATION_TEST_PROGRAMME]] once one exists.
Independent researchers are welcome to test this website within the scope set out in the vulnerability disclosure policy.
There is no availability commitment today. The Terms of Service say the same thing: no service level applies unless the parties agree one in writing, at [[SERVICE_LEVEL_COMMITMENT]].
We publish no uptime percentage. Nobody has measured one, and a figure nobody measured is worth nothing to you.
There is no public status page on this site.
Backup frequency and restore testing are at [[BACKUP_AND_RESTORE]]. Recovery time and recovery point objectives are at [[RECOVERY_OBJECTIVES]]. No recovery objective should be assumed until those are filled in.
How an incident is detected, escalated, and closed out is at [[INCIDENT_RESPONSE_PROCESS]].
When and how affected customers are told, and the window we commit to, is at [[NOTIFICATION_WINDOW]]. No notification window is committed on this page.
Suspected incidents and vulnerabilities should be reported to [[SECURITY_CONTACT_EMAIL]] through the disclosure policy below.
Neoteric makes no certification claim. There is no SOC 2 report, no ISO 27001 certificate, no HIPAA attestation, and no PCI assessment to give you, and nothing on this site should be read as suggesting one is under way.
No independent security audit of the product has taken place.
For a pre-release product that is a normal position, and saying so is more useful to a reviewer than a promise to work towards something. If it changes, the certificate, its scope, its auditor, and its date will be named on this page and nowhere else.
Insurance cover is at [[INSURANCE_COVER]]. Sub-processor commitments are at [[SUBPROCESSOR_LIST]]. The data processing agreement offered to customers is at [[DPA_REFERENCE]].
An RFC 9116 security contact file is prepared but withheld until the contact mailbox is provisioned, because publishing an unroutable reporting address would leave a researcher believing they had disclosed responsibly when nobody received the report.
Read the vulnerability disclosure policy before testing anything. It sets out what is in scope, what is not, what you must not do, and the safe harbour position.
The security mailbox is at [[SECURITY_CONTACT_EMAIL]]. Until it is confirmed as monitored, the disclosure policy says so rather than implying a report will be read.
If you are evaluating Autom and need answers to the items above, ask for them. A security questionnaire is a reasonable thing to send us, and for some of its questions the honest answer today is that the position has not been established.
Contact Sales is the route. Tell us which items you need and what decision they feed into, so the answer is useful rather than generic.
How diligence requests and security questionnaires are handled is at [[SECURITY_DOCUMENTATION_PACK]].
Report a security problem through the disclosure policy. Ask for anything this page leaves open through Contact Sales.
