AI Defence / Remedy architecture
Continuous Integrity is the planned system for comparing the present state of files, applications and security configuration with the state that justified earlier trust. Certification belongs to measured evidence and policy, rather than a familiar name.
A cryptographic content fingerprint identifies an exact object. State identity describes a broader approved configuration: an application’s executable, relevant modules, publisher, package source, services, extensions and security-sensitive settings. Either can change without a filename changing.
A document named Payroll.xlsx is not necessarily yesterday’s document. An executable named WINWORD.EXE is not automatically the installation previously evaluated. Remedy’s design measures the relevant object or state and records certification separately from customer content. It does not require adding a watermark or changing the file.
The proposed registry links an exact fingerprint to what was observed, where it came from, how it was evaluated and which policy supported its certification. Relevant records include type, source, publisher/signature, first and last observation, analysis outcome, rule or intelligence version and relationships to embedded components.
A readable Remedy reference helps an administrator discuss the object. The underlying cryptographic identity remains authoritative. An illustrative reference such as REM-74472166 would be a label for the record, not proof of safety and not a confirmed production interface. Re-encountering an identical object may allow relevant evidence to be reused, subject to freshness and policy.
Read-time checking means comparing the current protected object with the certified measurement when that object is about to be used. A match can support the appropriate fast path. A mismatch causes the earlier certification to be held while the change is explained and evaluated.
The proposed outcomes include recertification, restricted use, Glass analysis or quarantine. A hash alone does not identify intent, and a clean measurement does not establish that every surrounding process is healthy. Certification needs scope: which object, which state, which policy, which evidence and which time.
Consider Payroll v42 opened in an approved application by an authenticated employee, edited through an expected operation and saved as v43. The new fingerprint is different, but the provenance chain explains the change. This can support a lighter recertification path appropriate to policy.
Compare that with an unexplained replacement or modification by an unexpected process. The new state should not silently inherit the earlier object’s authority. Ordinary business work remains possible because an explained change and an unexplained change are evaluated differently. Authorised origin remains evidence to assess, rather than a universal guarantee.
| Observed change | Relevant evidence | Intended treatment |
|---|---|---|
| Normal document save | Approved application, authenticated user, expected operation | Evaluate the new version through authorised lineage |
| Signed vendor update | Package source, signature, changed modules and policy | Revalidate the resulting installation |
| Unexplained replacement | Fingerprint mismatch and missing or unexpected lineage | Hold inherited trust; investigate or isolate |
The measured scope can include executables, DLLs and modules, scripts, browser extensions, services, scheduled tasks, startup entries, container images and important configuration. A legitimate update can change several of these at once; the whole relevant resulting state needs evaluation.
Security drift is a departure from the approved posture: protection disabled, a firewall rule altered, a new local administrator, a stopped agent, an unexpected package source or a modified service binary. The existing Linux development monitoring samples selected integrity and configuration changes. Full continuous certification and estate-wide revocation remain planned extensions.
A signed dependency update is useful provenance, not permanent immunity. Changes in package source, new modules or unexpected extensions may require stronger revalidation. This approach supports supply-chain risk management without claiming to detect every compromised supplier or malicious update.
The bytes may be unchanged while security knowledge changes. New intelligence might identify an embedded component that was previously unknown. A policy may also become stricter or a certificate may be revoked. The registry is intended to locate affected observations and reconsider prior certifications.
Trust therefore has a lifecycle: new, measured, evaluated, certified, monitored, changed or newly risky, then revalidated. Restricted, pending, inconclusive, quarantined and revoked states preserve information that a binary green/red label loses. Restoration of normal authority requires sufficient new evidence.
File integrity monitoring detects changes; mature tools may also explain and validate them. Remedy’s planned model connects those changes to certification, authority, isolation and subsequent remediation evidence.
No. Legitimate editing and updates change fingerprints. The design evaluates the provenance and resulting state before determining whether a change deserves normal use, additional analysis or restriction.
No. It is a scoped decision based on evidence and policy at a point in time. Changes in the object, its context or relevant intelligence can invalidate that decision.
Talk directly to Altari
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.
