Documentation

Merlin — Technical Reference

This page describes how Merlin technically operates — its capability classes, the credential boundary, and how approval works before anything executes. For what Merlin is and the philosophy behind it, see Merlin. For current capability status, see Capabilities.

Capability Classes

Everything Merlin does falls into one of four capability classes. (Source: Merlin architecture documentation)

Observe— gathering real KEEP state (incidents, logs, scans, telemetry) that Merlin reasons about. Merlin never originates this data itself; it's the same real state visible elsewhere in KEEP.

Analyze — reasoning over observed state to produce a diagnosis or explanation.

Correlate— connecting observations across devices, incidents, or time to surface a pattern a single observation wouldn't show on its own.

Recommend — stating a conclusion and a suggested action, traceable back to what was observed, analyzed, or correlated.

The Credential Boundary

Merlin's reasoning calls only ever receive descriptive information — a device's condition history, an event log excerpt, a CVE name and severity score — never a password, key, or credential. When a human authorizes an action that actually requires one, the credential is entered directly into KEEP and used by KEEP's own server code to carry it out. Merlin's reasoning and any credentialed action are always two separate steps, never a single combined call. (Source: Merlin architecture documentation)

Approval Mechanics

Two shapes exist for authorizing an action Merlin proposes. (Source: Merlin architecture documentation)

Live confirmation (the default): Merlin proposes an action, a human explicitly approves it in the moment, and only then does KEEP execute it.

Standing pre-authorization(opt-in): a Director configures a rule in advance, in plain language, and signs off on it once. From that point on, KEEP evaluates the stored rule deterministically at the moment it's triggered — it does not re-invoke the AI model live. This is a reliability requirement (latency, cost, and misinterpretation risk are all wrong for a live-triggered decision), not a style preference. (Source: Merlin architecture documentation)

Continue Reading

For Merlin's identity and the philosophy that governs it, see Merlin. For what's built today and how thoroughly it's been validated, see Capabilities.