"Active Directory, passively managed."

directory-pacifier

An LLM-assisted Windows/AD fleet management agent for a homelab environment. The system uses an LLM (Anthropic API initially, local acceleration later) to bridge general systems expertise with AD/Windows domain administration knowledge, providing visibility, diagnosis, and assisted remediation without requiring the operator to be an AD expert.

Architecture

Three components with explicit privilege separation:

• Control loop (low-privilege) — drives the LLM, evaluates advisory policy rules, proposes operations, manages user interaction for approvals. Untrusted by construction; does not participate in the execution trust chain.
• Approval store (Postgres via CNPG) — append-only by role enforcement. Stores proposed operations with a cryptographic commitment to the exact operation request, approval/rejection records (single-use, time-bounded), execution records, and the trust ledger. Observable independently by both the control loop and the RPC server. Doubles as audit log.
• RPC server (high-privilege) — executes operations against the Windows/AD fleet. Independently evaluates mandatory policy rules and verifies approval exists in the store for the exact operation received. Does not trust the control loop's claims about anything.

Policy system

Two lanes in a shared policy language:

• Advisory rules — provided to the LLM as context to inform its judgment. Can be expressive and rich.
• Mandatory rules — evaluated by a rules engine inside the RPC server. Simple by design. LLM cannot override. Result is final.

Trust model

Trust accumulates explicitly over time, per operation type and scope. The agent proposes trust reductions after demonstrated success; the operator grants them deliberately. Scope is a first-class dimension — fleet-wide operations do not inherit trust from single-host operations of the same type.

Universe model

Operations act on subjects within universes. A universe is a first-class entity with a driver that provides member enumeration, subject validation, and a vocabulary of subject kinds and scope descriptors. Drivers are composable via a decorator pattern — a user-defined universe ("my three favorite computers", "domain controllers only") is the AD driver with a filter decorator applied, inheriting the full AD vocabulary and validation while constraining membership. Universe driver configuration is stored as JSONB in Postgres; credentials are referenced from OpenBao rather than stored directly.

Built-in universe kinds initially: ad_domain, user_defined. Driver interface is designed for future extension (Kubernetes, SSH fleet, etc.).

Management layer

DSC push mode for desired state operations, direct PowerShell reads for interrogation and diagnosis, Prometheus + windows_exporter for metrics. windows_exporter fleet installation is the first concrete operation target and the initial driver for proving the architecture end-to-end.

Implementation

Go. Postgres (CNPG). OpenBao for secrets. Deployed to the c2-talos Kubernetes cluster.