Will Your AI Touch My Estate?
The first question every security leader asks about AI in the security stack. Chronolith can act on endpoints. The AI inside it cannot — and that is a property of the architecture, not a setting somebody could switch on.
In short
- The AI advises. It never executes. There is no code path from the advisory layer to anything that runs, and a build-time test fails if one ever appears.
- Three tiers: advise, click-to-execute, and pre-authorised. Everything the AI produces is permanently capped at the first.
- Irreversible or estate-wide actions cannot run unattended — not by default, not configurably. The ceiling is calculated from the action's own properties.
- An allowlist, not a blocklist. Anything not explicitly registered in reviewed code is refused and logged.
- Refusals are audited as carefully as successes, so a repeated attempt to run something forbidden leaves a record.
What can your AI do to my systems at 3am?
Most vendors answer with a policy — a setting, a confirmation dialogue, a promise about how the model was trained. Every one of those is revocable by a configuration change, a rushed administrator, or a bug.
Chronolith answers structurally. The part that reads your telemetry and reasons about it has no callable path to the code that executes anything. The path is not disabled, and it is not a permission the AI lacks. It does not exist.
A policy answer asks you to trust an implementation. A structural answer can be demonstrated. If this ever has to be explained to a regulator, an insurer or opposing counsel, the defensible sentence is “the system was built so that action could not execute autonomously”.
Three tiers of authority
Every action belongs to exactly one tier, enforced at the moment of execution.
An action does not get to declare which tier it qualifies for. The maximum is derived from its own properties, so nothing can be registered claiming authority its shape does not support.
Irreversible or estate-wide actions cannot run unattended. An administrator cannot enable it and the AI cannot request it.
Why an allowlist rather than a list of forbidden actions
Adding an action is a code change that goes through review, and the list cannot be edited while the system is running — a boundary that can be modified at runtime is not a boundary.
Five checks before anything runs
Everything passes one gate. Any failure refuses and records.
- The action is registeredUnregistered means unexecutable.
- Its tier is within its ceilingApplied at run time, not trusted from configuration.
- A valid human authorisation existsA short-lived token, or a standing grant.
- Parameters validate exactlyAgainst a declared schema, with no free-form fields.
- Blast radius is within boundsAn action scoped to one machine cannot be aimed wider.
A system that logs only what ran leaves no trace of the thing you most want to see afterwards: something repeatedly trying to do what it is not allowed to do. Every refusal is written with the actor, the action, and the reason.
How we prove the separation holds
A claim like this is only meaningful if it survives the next hundred code changes. A developer adding a convenient shortcut would not think of themselves as granting an AI execution authority — which is exactly why it is checked mechanically rather than by review.
A test walks the entire codebase before every release. Any component that can reach the language model, plus the whole advisory layer, is checked for a route to the execution machinery. If one exists, the build fails.
The set of components checked is worked out automatically, not maintained by hand. An earlier version listed them manually — and a component that reached both the model and the execution path passed that version. The automatic version caught it.
What Chronolith can actually do to an estate
The list is short on purpose, and it is the honest measure of Chronolith's reach. It grows one reviewed entry at a time.
| Action | Status |
|---|---|
| Sign one account out of the machines it is logged into | Available |
| End sessions across a bounded scope | Available |
| Request a replacement certificate | Available |
| Bind an issued certificate to a service | Available |
| Deploy a certificate to the appliance | Available |
| Probe your own address ranges for unmonitored devices | Available |
| Rotate a root certificate authority | |
| Anything destructive or estate-wide | |
| Change file share permissions |
Chronolith will tell you a client folder is open to Everyone, when it changed and who changed it, and generate the correcting command. It will not run it — a bulk permission change can lock a firm out of its own documents, and from the user's side that is indistinguishable from ransomware.
Common questions
Can we turn on full automation if we want it?
For reversible, tightly scoped actions, yes — that is what the pre-authorised tier is for, and it requires a deliberate human grant. For anything irreversible or estate-wide, no. That is not a setting we have chosen to withhold; the architecture has no route to it.
Does the AI see our data, and where does it go?
Chronolith runs on your premises with no cloud dependency for collection, storage, search or reporting. AI-assisted features are optional and the model layer is deliberately vendor-agnostic, so the AI can be pointed at infrastructure you control. Whatever sits behind that interface, the authority boundary described here is unchanged — it constrains what can execute, not which model is answering.
What happens if the AI is wrong?
It produces a suggestion that a person reads and either acts on or discards. A wrong suggestion costs someone thirty seconds. It cannot cost an outage, because it cannot reach anything that runs.
How do we verify any of this ourselves?
Ask for the registered action list — it is short, and it is the complete set of things the product can do. In a technical review we will walk through the gate sequence and the separation test directly.
Could someone compromise the appliance and use it to attack us?
The reachable actions are the registered ones, and that list cannot be extended at runtime — adding to it requires shipping reviewed code. Actions still need valid authorisation, and every attempt, including refused ones, is recorded. That does not make compromise harmless, but it bounds what a compromised appliance can reach and leaves evidence of any attempt.