Know what is collected. Agree where it goes.

Data observed on the host

Linux collectors assemble system, account, network, service, storage, security, application, container, process and relevant cloud-configuration facts. Monitoring adds selected integrity hashes, configuration digests, process observations and authentication-log samples.

Depending on the inputs, this can expose usernames, addresses, software versions, paths, command context and log records. The exact collection scope must be checked against the configured collectors. Do not assume that “metadata” is free of personal or confidential information.

Transmission and local buffering

The shared transport code supports HTTPS, certificate configuration and signed message envelopes. The example leaves transport disabled. Real operation needs certificate provisioning, correct endpoint configuration, key custody and receiving-service validation.

The implementation also includes offline queuing. Queue capacity, storage permissions, durability, encryption at rest and deletion behaviour have not been established here as end-to-end deployment controls. Verify them before collecting sensitive customer information.

Redaction and access boundaries

The Linux findings pipeline applies redaction, but this is not proof that every possible secret or personal value is removed from all outputs. Test representative report and message samples against the collection policy before enabling delivery.

The related Remedy HostService has separate bounded evidence, permissions, target allowlists and replay checks. These cannot be treated as proof that every AI Defence component shares the same access boundary. Tenant separation, administrative permissions and the receiving application need integration-specific evidence.

Evidence integrity and audit records

The central development packages contain signed-evidence and audit-related structures. Later review material identifies unresolved issues in verifying signatures at the execution boundary, matching observers, recording durable cleanup and distinguishing local audit checkpoints from external anchoring.

Accordingly, this site does not promise immutable audit, guaranteed end-to-end evidence verification or independently anchored production records. Those properties require review and deployment evidence before they can be used as assurance claims.

AI processing and external recipients

The AI Defence planner has an advisory recommendation interface, but an active model integration and its data flow have not been verified. The separate Remedy source contains model-backed agents; that does not establish which provider would process AI Defence evidence.

Before enabling AI-assisted processing, agree the input fields, redaction, provider or local service, processing location, retention, training terms and access. No local-only inference, zero data egress, proprietary training or provider privacy guarantee is asserted here.

Hosting, retention, deletion and organisational policy

Customer hosting regions, storage encryption, backups, retention periods, deletion verification and subprocessors must be specified for the chosen deployment. Public website hosting is not evidence of where security telemetry will be processed.

The public site contains no analytics or marketing tracker added by this update. Its product tour uses synthetic records and makes no security-service requests. Contact is through the existing Altari email address; your email service sends the information when you choose to send a message.

A published, applicable organisational privacy notice and contractual processing terms need to be supplied by Altari. This page does not replace them or claim certification, regulatory compliance or approval for critical infrastructure.

Reporting a security concern

Use the existing Altari contact route to report that a security concern needs attention. Start with a brief, non-sensitive description and request an appropriate channel before sending credentials, complete logs or detailed customer evidence.

Support response commitments and vulnerability-disclosure arrangements need agreement for the engagement. This website does not create a contractual response deadline.

Bounded evidence for the wider architecture

Glass and Continuous Integrity may need to inspect files, code, embedded scripts and relevant behavioural traces. The design principle is to collect only what the decision needs, keeping certification and provenance records separate from customer content.

Where AI assistance is appropriate, bounded technical artefacts are preferable to unnecessarily sending complete confidential documents to an external model. Redaction, permitted data categories, provider choice and tenant policy require explicit controls. A general minimisation principle is not proof that every possible sensitive field is removed.

The intended evidence model includes fingerprints, policy and rule versions, device identity, timestamps, relevant telemetry and action/verification results. Retention, residency, access, deletion and subprocessors must be confirmed for the actual deployment; no additional privacy or legal guarantee is inferred from this architecture.