Argos OS · Trust & assurance
How Intelligent Automation protects the security, availability and privacy of the data you and your clients entrust to the Argos OS platform — what we do, how it is verified, and what we do not yet claim.
Abstract
If you are reading this, you are most likely evaluating whether to let Argos OS into networks you are responsible for — your own, or your clients’. That is the right question to ask of any platform, and this document exists to answer it in specifics rather than adjectives.
How the platform is architected and operated to protect data: encryption, tenant isolation, identity, application and infrastructure controls, and how vulnerabilities are found and fixed.
How the service stays up, how changes are controlled, and what happens in a failure — including what has actually been tested rather than merely planned.
What data we collect, where it is stored, how long we keep it, who else touches it, and how you get it back or have it deleted.
Trust documents have a tendency to describe an aspiration in the present tense. We have tried hard not to do that. Every control described here is one we operate today, and where a figure appears it was measured on the platform rather than estimated.
Where we do not yet have something — an attestation, a certification, a formal programme — it is stated plainly in the next section rather than omitted. We would rather you find the gaps here than find them yourself later.
Certification posture
This section is deliberately first among the substantive sections. A trust document that buries its certification status is not a trust document. Frameworks we work to are distinguished from certifications we hold, because the difference matters and is frequently blurred.
| Framework or attestation | Status | What that means here |
|---|---|---|
| CIS Controls v8 | In use | Adopted as the working control framework for the platform and for the client environments we manage. Control mappings are maintained in our governance platform. |
| NIST CSF 2.0 | In use | Used as the organising model for security programme structure and for client assessments. |
| OWASP | In use | Application security practice is written against OWASP guidance; dependency and image scanning run continuously against the platform. |
| SOC 2 Type 2 | Readiness | We do not hold a SOC 2 attestation. Readiness work is underway and control evidence is being collected in our own governance platform. We will not describe ourselves as “SOC 2 compliant” before an auditor says so. |
| ISO/IEC 27001 | Not held | We are not certified to ISO/IEC 27001. Where a client requires a certified provider for a specific workload, we will say so rather than argue the point. |
| PCI DSS v4 | Out of scope by design | We do not store, process or transmit cardholder data. Payment flows are handled by PCI-certified third parties; card numbers never reach our infrastructure. |
| HIPAA | Per-engagement | Handled contractually per engagement where protected health information is in scope, with a business associate agreement. Not a blanket platform claim. |
| Third-party penetration test | Planned | Internal offensive testing is performed. An independent third-party penetration test of the platform is on the roadmap and is not yet complete. |
A certification is a statement that an independent party examined something. Claiming one you do not hold is the fastest way to lose a client permanently, and the claim is trivially checkable. Our position is that a smaller set of true statements is worth more than a longer list of impressive ones — and that a provider who tells you where they are weak is giving you the information you actually need to make a decision.
Principles
No single control is trusted to be the one that holds. The platform layers independent controls at the network edge, the host, the application, the data and the identity layers, so that the failure of any one of them is contained rather than decisive.
Breadth matters as much as depth: a control that covers most of the estate and quietly misses a corner is the corner an attacker finds. Coverage is measured, not assumed — several of the figures in this document exist because we went and counted.
Our operating experience is that the dangerous failures are silent ones: a scheduled job that exits zero without doing anything, a monitor that reports healthy because it is asking the wrong question, a backup that has never been restored.
The practical consequence is that verification is treated as a control in its own right. Backups are restored on a schedule, not merely taken. Monitors are required to discriminate between healthy and unhealthy rather than merely respond. Coverage claims are re-counted rather than carried forward.
Access to client environments is scoped and audited. Automation runs under dedicated, narrowly-scoped identities rather than a person’s credentials — when we found a backup path running on an individual’s personal authorisation, we replaced it with a purpose-built application identity restricted to a single destination rather than simply rotating the credential.
Internal security findings are tracked to a demonstrated fix. We keep a running internal record of our own incidents and near-misses, including credential-handling mistakes, with the root cause and the control change that followed. That record is what drives the engineering rules the platform is built under.
Security — data
All access to Argos OS services is over TLS. Public endpoints were verified at the time of writing to negotiate modern protocols only.
| Protocol | Accepted | Notes |
|---|---|---|
| TLS 1.3 | Yes | Preferred. Negotiates AES-256-GCM. |
| TLS 1.2 | Yes | Forward-secret ECDHE key exchange with AES-256-GCM or ChaCha20-Poly1305. |
| TLS 1.1 | Rejected | Deprecated by RFC 8996. Handshake refused. |
| TLS 1.0 | Rejected | Deprecated by RFC 8996. Handshake refused. |
HTTP Strict Transport Security is enforced with includeSubDomains,
and the primary domain is submitted to the browser preload list, so a browser will refuse to make a
plaintext connection even on a first visit. Responses additionally carry content-type sniffing
protection, framing restrictions, a strict referrer policy and a permissions policy that denies
geolocation, microphone and camera access by default.
Persistent data is stored on encrypted volumes. Application-level encryption is applied to secrets and to sensitive credential material, and secret material used by platform services is held in a dedicated secrets store rather than in application configuration.
Off-site backups of every service database, and of platform secrets, are encrypted before they leave the platform, using asymmetric encryption to a public recipient key.
The private key that decrypts our backups is not on the platform. It is held offline, off-infrastructure, in the principal’s custody in more than one location. An attacker who obtains complete control of our infrastructure — including the backup storage credentials — obtains ciphertext. This is a deliberate design choice: it means the backup estate is not a second copy of the attack surface.
Backups are written to a storage provider that is deliberately independent of our infrastructure provider, so that the loss of one supplier does not take the recovery path with it. Retention runs on a ninety-day ladder.
We do not store card numbers. Payment processing is delegated to PCI-certified providers and card data does not transit our infrastructure. Billing integrations operate by link-out to the payment provider rather than by handling card details in our applications.
Security — multi-tenancy
Argos OS is multi-tenant. If you are a service provider, your clients are tenants within your account, and other service providers are tenants alongside you. Isolation is therefore not a feature of the platform — it is the platform’s central safety property, and for the large majority of tables it is enforced in the database rather than in application code. Where that is not true — the administrative-bypass tables described below — we say so rather than letting a general statement cover a specific exception.
Operational business data — tickets, clients, contracts, documentation — is separated by giving each tenant its own database schema. A query issued in one tenant’s context cannot name another tenant’s objects. Isolation is structural rather than a filter that must be remembered.
Where data is shared in common tables, isolation is enforced by PostgreSQL row-level security. Every applicable table in the security platform’s primary schema — 188 of 188 at the time of writing — has row-level security both enabled and forced, with a policy attached to each.
The distinction between enabled and forced matters and is often missed. Enabled row-level security does not apply to the table owner; forced row-level security applies to everyone, including the owner. Enforcement therefore does not depend on which database role an application happens to connect as.
But coverage is not the same as isolation, and we will not present it as such. A policy can be enabled and forced and still express “reachable only under the platform administrative role” rather than “scoped to a tenant”. Such a policy isolates nothing on its own. The honest statement is therefore two numbers, not one: 188 of 188 tables carry a forced policy; 152 of those policies are tenant-scoped, and 36 are administrative-bypass only. That is roughly one table in five, which is too many to describe as an exception, so we describe it as what it is and reduce it deliberately — see below.
Authentication is delegated to a dedicated identity provider in which each tenant is a separate organisation with its own users, policies and administrators. Tokens carry tenant context, and services resolve tenant identity from the token rather than from user-supplied input.
36 tables are reachable only under an explicit administrative bypass role. These are cross-tenant operational tables — inventory caches, platform mappings, scan and telemetry staging — rather than customer business records, which are schema-separated and tenant-scoped. Use of that role is deliberate, limited to platform operations, and audited.
For these tables, confinement to a single tenant is enforced in application query logic rather than by a database policy. The database gate is real but coarse: it admits the platform administrative role and refuses everyone else, so the tables are fail-closed rather than world-readable — but the fine-grained “which tenant” decision sits one layer up. We state that explicitly because “enabled and forced” would otherwise imply the database is doing work it is not doing for this subset.
We publish the count rather than the adjective. An earlier edition of this document said “a small, defined set”, which was true but unquantified, and unquantified is how a reasonable claim becomes a misleading one. Reducing this set — and moving that enforcement down into the database — is active engineering work, and the number will move in one direction. If it has not moved by the next edition, that will be visible here.
Security — application
Changes are reviewed before they ship, and a review that raises a finding blocks the deployment rather than accompanying it. Automated gates run in the pipeline: language-level build and compile checks, syntax validation of anything served to a browser, container build verification, and a secret-detection hook that refuses commits and command invocations containing credential material.
Database migrations are treated as a distinct risk class requiring explicit approval, with idempotency and rollback considered before application.
A deployment is not complete when the container starts. Service logs are inspected after every deployment, container state is confirmed, and health endpoints are exercised. If the logs show errors, the change is treated as failed and is fixed before anything is recorded as done.
This rule exists because we have had a deployment appear successful while breaking authentication for the whole platform. Verification now includes an explicit sign-in check after changes to services in the authentication path.
Every service that accepts file uploads — the service desk, the client portals, the secure message portal and the hosting platform — runs an anti-malware engine against uploaded content. Scanning is per-service and in-line with ingest rather than a periodic sweep of storage.
Application code is written against OWASP guidance, with particular attention to injection, access control and the handling of untrusted input. Authorisation is enforced server-side on every write path; we treat client-side gating as a usability affordance and never as a control.
Security — infrastructure
Public services sit behind a CDN and web application firewall providing DDoS absorption, TLS termination to modern protocols only, and request filtering. Origin infrastructure is not directly addressable for the services fronted this way.
Administrative interfaces are not exposed to the public internet on their own; where they are reachable, they sit behind an authenticating proxy in addition to the application’s own authentication.
A behavioural intrusion prevention system parses live web traffic and applies blocking decisions at the host firewall, combining locally-derived decisions with a community threat feed.
At the time of writing it was holding 5,770 active blocking decisions and had processed 110.5 million packets in the preceding week. These are measured operational figures, not capability claims.
Services run as isolated containers on segmented internal networks, with inter-service communication restricted to declared networks rather than the host network. Privileged access to the container runtime is brokered through a restricted socket proxy rather than by mounting the runtime socket into management tooling directly.
Infrastructure administration is performed over an authenticated private overlay network rather than public remote access. Public remote-administration ports are not exposed. Administrative actions are attributable to an individual.
Security — identity
Authentication is handled by a dedicated identity provider rather than hand-rolled application authentication. Supported methods include password with time-based one-time-password multi-factor authentication, and federated sign-in with Microsoft and Google. Enterprise single sign-on is supported through the same provider.
Access is role-based and enforced server-side. Write operations are gated on role at the API boundary, not only in the interface. Where a capability is restricted, the restriction is enforced at the route and, for tenant data, again at the database.
Sensitive cross-tenant operations require two distinct approvers. High-impact automated actions require either two approvals or an explicit, time-bounded break-glass path that is recorded and reviewable.
We operate an absolute internal rule that credential values are never printed, logged, echoed, pasted into tickets or captured in screenshots — not truncated, not partially masked, not “just the prefix”. Verification of a secret is performed by comparing hashes, never by displaying the value.
This rule is enforced by tooling that blocks commands and commits containing credential material, and it exists because we learned that attempting to redact is itself the failure mode — masking rules miss unlabelled values and length-based truncation silently does nothing to a value of the wrong length. Customer credentials supplied to us for device or system access are transmitted through a dedicated secure message portal, written directly to restricted storage, and never routed through chat, email or a commit.
Security — vulnerabilities
Scanning runs continuously and in layers, because a single scanner has a characteristic blind spot and the blind spot is where the incident comes from.
| Layer | Cadence | What it covers |
|---|---|---|
| Deployment tree scan | Daily | Filesystem-level dependency scanning of every deployed service tree. |
| Running-image scan | Daily | Vulnerability scanning of the images actually running, plus version-drift detection between sibling services. This layer exists because tree scanning is blind to dependencies baked into an image — a gap that once let a critical framework vulnerability sit undetected. |
| Host security scan | Weekly | Operating-system and host configuration. |
| Advisory watch | Continuous | Queries vendor and ecosystem advisory sources in addition to CVE feeds, because a significant number of advisories for components we run never receive a CVE identifier and are therefore invisible to CVE-only scanning. |
| Cloud posture scan | Nightly | Configuration posture of the productivity and identity tenancy. |
We discovered that a component in our stack carried multiple critical published advisories, the majority of which had no CVE identifier at all — meaning a conventional scanner reported the component clean. Scanning only for CVEs produces a green result and a false sense of coverage. That is why advisory watch is a distinct layer here rather than a footnote to the scanner.
Security — detection
Platform and client environments are monitored continuously for availability, error conditions, configuration change and security events. Alerts route to an on-call path with escalation, and acknowledgement is cryptographically signed so that an acknowledgement is attributable and cannot be replayed.
Monitors are required to discriminate — a check that returns healthy whenever the service responds at all is treated as a defect, because it converts an outage into silence.
Security incidents follow a defined response path: contain, preserve evidence, establish scope, remediate, and record the root cause with the control change that prevents recurrence.
Where an incident involves credential exposure, our standing rule is immediate disclosure internally, full rotation, and a written record — explicitly not quiet continuation. Where a customer is affected, we notify. Commitment — notification timeframe pending approval.
Platform services write to a shared audit spine with cross-service linkage, so an action can be traced across the services it touched. Signature and approval events are recorded in a hash-chained ledger, making retrospective alteration of the record detectable rather than merely prohibited.
Platform and client-facing service status is published on public status pages, independently of the platform’s own interfaces, so that status is observable when the platform itself is not.
Availability
The platform runs as a high-availability pair. On host failure, the shadow host takes over in approximately sixty seconds with a data-loss window of no more than five minutes. This covers hardware and host-level failure. It deliberately does not cover corruption, deletion or ransomware — all of which replicate to the shadow — which is the job of the recovery estate described in the next section.
Compute, memory and storage utilisation are monitored with alerting on headroom thresholds. Capacity is reviewed as services are added, and the platform has been scaled during its life in response to that review rather than after an incident.
We are not publishing an uptime percentage in this edition. We operate continuous availability monitoring and public status pages, but we have not yet established a measured, independently reproducible service-level figure that we are willing to put in a document of this kind. When we can compute one honestly, it will appear here. An uptime number that cannot be reproduced from monitoring data is marketing, not assurance.
Availability — recovery
This is the section we would most want a prospective customer to read, because it is the one where the difference between a plan and a practice is easiest to see.
Every service database; platform secrets and service configuration; and the source code estate. Secrets are included deliberately — we found during a review that code and databases were protected while the configuration needed to boot them was not, which would have left a restored platform unbootable.
To a storage provider independent of the infrastructure provider, so that losing the supplier does not lose the recovery path. Encryption is applied before transfer, and the decryption key is not held on the platform.
A weekly verification job checks that every service has a fresh local and off-site encrypted backup, and alerts if any does not. A monthly self-test performs the complete round trip — dump, encrypt, upload, retrieve, decrypt, restore — and verifies the restored data by row count. That round trip has been executed and passed, proving the mechanism.
Verified 10 September 2026: every active service has a current off-site copy. On that date a review found two defects and both are fixed. Dumps were written directly to their final filename, so the transfer job could begin copying a file that was still being written; dumps are now written under a temporary name and renamed on completion, which makes a partial file unselectable rather than merely unlikely. Separately, the verification job itself carried a shell defect that produced false negatives once the remote listing grew past a buffer threshold — it reported missing copies that were in fact present. Both were found by inspection rather than by an incident, and the verification job now runs daily instead of weekly. We record this here because a trust document that only lists controls, and never the occasions they were found wanting, is not evidence of anything.
Host failure is covered by the high-availability pair with an approximately sixty-second failover and a five-minute data-loss window. Recovery from data loss or corruption is from the off-site estate. Commitment — formal RTO and RPO targets pending approval. We are not stating recovery-time numbers we have not yet measured under a full rebuild.
Privacy
Platform data is stored on infrastructure in the United States, with off-site backup replication to a separate provider. Commitment — exact residency wording and provider naming pending approval.
We use a small number of third parties for specific functions — infrastructure hosting, off-site backup storage, payment processing, transactional email and productivity services. Commitment — a published sub-processor list is required and is not yet produced. Until it is, it is available on request.
Data is retained while you are a customer and for the period required to meet legal and contractual obligations. On termination, data is removed from active systems and ages out of the encrypted backup ladder. Commitment — specific retention and deletion timeframes pending approval.
You can view, correct and export your data from the platform. You may request deletion. A data processing agreement is available on request. Commitment — a standard data processing agreement and a formal privacy notice for the platform are required and not yet published.
AI & automation
Argos OS uses AI agents for triage, summarisation and, in defined cases, automated response. We consider it a basic obligation to state in writing what those agents may do unsupervised, because “AI-powered” on its own tells you nothing about whether something can take your systems offline.
Automated response begins in shadow for every customer and every action type: the agent performs its full reasoning and records the action it would have taken, and takes none.
Where enabled, it advances to supervised: the agent triages and proposes, and a person approves before anything executes. Approval is explicit, attributable and signed. This is the state the platform operates in today.
The third state, autonomous, is a deliberate per-customer, per-action decision gated on evidence rather than on confidence — and as of this edition, no action type is armed for autonomous execution for any customer. The calibration threshold described below has not been met, so it has not been granted. We would rather tell you that than describe a capability as though it were in use.
An action requires agreement between genuinely independent signals. Two rules reading the same table are one source, not two. A single sensor never triggers an action on its own.
A composite confidence score must clear a high threshold. The agent’s own stated confidence is one input to that score, never the gate itself — a model asserting it is certain is not evidence that it is.
The prior state is captured before any action is taken, and a reversal path must exist. An action that cannot be undone is not eligible for automation at all, regardless of confidence.
Hard per-customer caps per hour and per day. A faulty detection produces a small number of mistakes to investigate, not a cascade. A kill switch returns everything to shadow immediately.
An action type arms for a given customer only after a minimum number of scored decisions at a high measured precision on that customer’s own data, graded by an operator. Accuracy elsewhere does not transfer.
Below the automatic threshold but above the noise floor, the agent proposes rather than acts. Approval is explicit, attributable and signed. Below that band it enriches and summarises only. This band is where the platform operates today — a proposal is not an action until a person accepts it.
Agent reasoning, evidence, decision and outcome are recorded on the same audit spine as human actions, with model interactions hash-chained. You can ask what the agent did, why, on what evidence, and reverse it.
Customer data included in AI processing is limited to what the specific function requires. Commitment — a full statement of AI sub-processors, data residency for model inference, and training-use position is required and is not yet published. Our position is that customer data is not used to train third-party models; this needs to be stated formally with the provider terms cited.
Appendix
The body of this document concerns how we protect your data. This appendix is the other direction: the platform capabilities that improve the security posture of the environments you run on it.
Continuous discovery of what is actually on a network, with alerting on new and unexpected devices. You cannot protect an estate you have not enumerated.
Visibility of listening services and externally-reachable ports across monitored networks, with change detection.
Ingest of vulnerability scanner output across multiple formats, correlated with threat intelligence including known-exploited status — so remediation is ordered by real risk rather than by raw severity score.
Integration with endpoint protection platforms for alert ingestion, threat hunting across the data lake, and host isolation where authorised.
Framework-mapped control management with evidence collection, so that audit preparation is a continuous state rather than an annual scramble.
Security awareness training with phishing, smishing and vishing simulation, measured per user rather than reported as a completion percentage.
Continuous assessment of cloud identity and productivity tenancy configuration against a hardening baseline.
Vendor risk assessment and monitoring of the suppliers your clients depend on, including external attack-surface and domain-impersonation monitoring.
Incident response planning, on-call escalation with signed acknowledgement, and a documented, auditable response record.
Before release
The following items are commitments rather than descriptions. They create obligations to customers and should not be published without explicit approval, and in some cases without legal review. They are listed here rather than quietly softened in the text.
| Item | Section | What is needed |
|---|---|---|
| Breach notification timeframe | Incident response | A stated window (Domotz commits to 72 hours under GDPR). Needs a decision and, ideally, legal review. |
| Formal RTO and RPO | Backup & recovery | Measured recovery-time objective from a full rebuild exercise, not an estimate. Requires running the exercise and timing it. |
| Data residency wording | Privacy | Confirmation of how precisely we describe location, and whether infrastructure and backup providers are named publicly. |
| Published sub-processor list | Privacy | A named list with the function each performs. Expected by any customer doing vendor due diligence on us. |
| Retention and deletion periods | Privacy | Specific timeframes for active-system deletion and backup expiry. |
| Data processing agreement & privacy notice | Privacy | A standard DPA and a platform privacy notice. Referenced in this document; both need to exist. |
| AI data-handling statement | AI governance | Model providers named, inference residency, and a formal statement on training use with the provider terms cited. |
| Uptime figure | Availability | Deliberately omitted. Include only once it can be computed reproducibly from monitoring data. |
Two things in this document describe controls that are correct in design but where the current operational state should be confirmed before a customer reads them: