Continuous Reconciliation

The Principle

Continuously compare actual state to declared state. Detect drift. Correct it. The system does not merely apply changes when they are made. It continuously compares the actual state of each downstream system against the declared desired state. Deviations are detected, reported, and corrected, whether caused by manual intervention, automation errors, or external changes.

Why Drift Is Inevitable

Changes will be made outside the system. An administrator will grant emergency access directly in a console during an incident. A vendor's support team will enable a feature that includes additional permissions. A misconfigured automation in a downstream system will modify group memberships. An API change will cause a permission to behave differently than expected.

These things happen regardless of policy, training, or good intentions. The question is whether drift is detected, and how quickly.

The Reconciliation Loop

Continuous reconciliation closes this gap. The system periodically reads the actual state of each managed system, compares it to the declared state, and takes action on discrepancies. The action may be automatic correction: reverting the system to the declared state: or it may be an alert that requires human decision. The appropriate response depends on the system, the severity, and the organization's tolerance for automated correction.

What matters is that drift is visible. A manually-granted permission that exists outside the declared configuration is surfaced within the reconciliation cycle: typically hours, not months. The exact frequency is bounded by the number of downstream systems and their API rate limits. Organizations with dozens of integrations will likely reconcile on the order of hours, not minutes. This is still a transformation: the window between unauthorized change and detection shrinks from quarters to hours.

Least Privilege as Emergent Property

When access is defined declaratively, assigned through composable roles, and reconciled continuously, least privilege is not an aspiration: it is the default state. Users get what their role definitions specify. No more accumulates over time, because each reconciliation cycle enforces the declared state.

In the traditional model, access is additive and permanent. A person joins team A and gets team A's permissions. They move to team B and get team B's permissions: but no one revokes team A's. They cover for a colleague and get temporary access that is never removed. Over a career, permissions accumulate like sediment.

In the declarative model, a person's access is derived from their current assignments, not their history. When they move from team A to team B, their configuration changes: team A is removed, team B is added. The next reconciliation cycle revokes team A's access and provisions team B's. There is no accumulation, because the system does not remember what came before: it only knows what should exist now.

This is a structural property, not a procedural one. It does not depend on someone remembering to revoke old access. It is an inherent property of a system that continuously enforces declared state.

Antipatterns

• Drift is discovered during quarterly audits, not detected automatically.
• Access from a previous team persists after someone transfers to a new one.
• Manual changes in downstream consoles go undetected for weeks or months.
• The system applies changes but never verifies the result.