Declarative Access

Introduction

In organizations of more than a few dozen people, each person's access to systems spans multiple platforms: cloud providers, source code repositories, SaaS applications, databases, and internal tools. Each platform has its own permission model, its own admin console, and its own notion of what a role or group means. Managing access across this surface area through manual processes and the entropy-like nature of time, produces predictable failure modes: slow/irregular onboarding, delayed/incomplete offboarding, accumulated standing privilege, and audits that require reconstructing history from scattered logs.

Or to put it another way, a minimal amount of scale and entropy organically creates technical debt in the realm of access controls.

Declarative Access is a concept for managing identity and access that:

This concept can be applied to organizations using any identity provider and any combination of downstream systems. It does not prescribe a specific platform, vendor, or product. It describes properties of a well-managed access system, not features of a particular tool.

These factors draw on the same practices that transformed infrastructure management: defining desired state in versioned configuration, reviewing changes before they are applied, and using automation to close the gap between intent and reality. Infrastructure as Code replaced manual server provisioning with declarative definitions. Access as Code applies the same principle to identity: you map the access that exists across the organization and its systems, so you can manage that access from a single model rather than needing to do it stack by stack.

Our motivation is to raise awareness of some systemic problems we've seen in IAM and onboard/offboard processes, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology.

Access carries organizational and legal weight that infrastructure changes do not. And the techniques to manage infrastructure can easily be applied to the Access domain.

Who is this document for? It's for anyone dealing with unmanaged IAM complexity.

How the Factors Relate

The factors are not a checklist. They are a system with dependencies and interactions. Understanding how they relate helps when adopting them incrementally rather than all at once.

The foundation (I, II, V). Declarative Access, Single Source of Truth, and Fan-Out Provisioning form the core loop. You define access in configuration (I), store it in one authoritative repository (II), and automation translates those definitions into concrete permissions across all downstream systems (V). Without all three, the model doesn’t close: declarations without fan-out are just documentation, fan-out without a source of truth is just another script, and a source of truth without declarations is just a spreadsheet.

Structure (III, IV). Separation of Definition and Assignment and Composable Roles are how you organize the definitions. They determine whether the model scales gracefully or drowns in role proliferation. They depend on the foundation being in place — there is little value in separating definition from assignment if neither is declarative.

Governance (VI, VII, VIII). Informed Approval, Lifecycle Management, and Ephemeral Privilege control how the system operates over time. They depend on fan-out (V) to execute their decisions: approval means nothing without execution, lifecycle management means nothing without coordinated provisioning and revocation, and ephemeral privilege requires fan-out to enforce time bounds across all systems simultaneously.

Verification (IX, X). Continuous Reconciliation and Inherent Audit Trail are how you verify the system is working. They are independent of the governance factors — reconciliation checks that reality matches intent regardless of how the intent was produced, and the audit trail records history regardless of what that history contains. But they are most valuable when the other factors are in place: reconciling against a declarative model is more useful than reconciling against a spreadsheet.

Not all factors are required to start. An organization can begin with the foundation (I, II, V) and add governance and verification progressively. The factors degrade gracefully — each one provides value independently, and each additional factor compounds that value.

The Factors

I

Declarative Access

Define who should have access to what. Let automation make it so.

 II

Single Source of Truth

One place to look. One place to change. One place to trust.

 III

Separation of Definition and Assignment

Those who design the roles are not those who fill them.

 IV

Composable Roles

Build access from small, reusable, well-understood blocks.

 V

Fan-Out Provisioning

Define once. Apply everywhere.

 VI

Informed Approval

A human decides: with full visibility. A machine executes: precisely.

 VII

Lifecycle Management

Onboarding adds. Offboarding removes. Both are a single change with complete effect.

 VIII

Ephemeral Privilege

Standing access is a liability. Time-bound access is a design choice.

 IX

Continuous Reconciliation

Detect deviation. Correct it. Least privilege is the result.

 X

Inherent Audit Trail

The history of access is not a report to generate. It is a record that already exists.

What This Doesn't Solve

No framework covers all problems. The following are adjacent to declarative access but separate concerns, each with its own body of practice:

Secrets management: a natural extension. Tools like HashiCorp Vault or AWS Secrets Manager store and broker credentials: database passwords, API keys, certificates. These systems solve a different problem than identity management, but the principles here apply directly to who can access which secrets and under what conditions. An application team that manages external API credentials for their service does not need to see the database credentials that same service uses at runtime. Those are machine secrets, scoped to the runtime environment, not to the humans who deploy it. Declarative access defines the boundary: which roles can retrieve which classes of secret, with what temporal constraints, through what approval path. Vault enforces it at the machine layer. The access model and the secrets broker are complementary: one says who can ask for what, the other says whether the ask is valid and hands over the credential.

Device trust and endpoint security. Whether a person's laptop is managed, encrypted, and compliant is an orthogonal concern to what permissions they hold. A person with correct permissions on a compromised device is still a risk. Device trust is a precondition for access decisions, not part of the access model itself.

Network access and zero trust. Service-to-service communication, network segmentation, and mTLS identity are related but distinct. A service mesh identity is not a human identity. The principles here apply to people and their access to systems, not to systems and their access to each other. That said, user-level network controls like VPN access, wireless certificates, and remote desktop permissions fit naturally as downstream targets. When a person is removed from the configuration, revoking their VPN certificate and disconnecting active sessions is just another fan-out operation, no different from removing them from a SaaS application.

Physical access. Badge readers, door controllers, and building management systems that expose an API are fan-out targets like any other. Provisioning a badge when someone joins and revoking it when they leave is the same operation as provisioning and revoking a SaaS account. Physical keys (non-rotating, non-revocable, untraceable tokens that grant access to real spaces) are a liability in the same class as standing SSH keys or hardcoded credentials. The principles apply: if it doesn't rotate, if it can't be revoked from a single change, it's a problem the model is designed to solve.

Service accounts and machine identities. Organizations have identities that are not people: CI/CD deployers, monitoring agents, automated service accounts. The boundary is functional, not technical. A service account that represents an organizational role — the deployer for the payments service, the monitoring scraper for production — fits the model. It is an assignment to a role, subject to the same lifecycle, approval, and reconciliation as a person's assignment. Machine-to-machine authentication — service mesh mTLS, inter-service API keys, workloads authenticating to other workloads — is a separate domain. The distinction: if the identity represents an organizational function that should be reviewed, approved, and lifecycle-managed, it is in scope. If it is a service authenticating to another service at runtime, it is not.

These are not weaknesses of the model. They are its boundaries. An organization that adopts declarative access will still need solutions for these domains. The value of the framework is that it reduces the identity problem to something tractable, not that it removes all security concerns.

Getting There

The principles above describe a target state. Many organizations reading this will be starting from a different place: dozens of systems with inconsistent access models, years of accumulated permissions, and no single inventory of what exists. The gap between here and there is the hardest part of the project. The following is a rough sketch of how the transition typically works, not a rigid methodology.

The social side is harder than the technical side. Writing integrations is engineering work with engineering problems. Getting people to stop clicking in admin consoles is a culture change. Every phase below has a technical component and an organizational one. Underestimate the organizational component at your peril.

Discover

Before anything can be declared, it must be understood. The first phase is discovery: inventory each system that manages identity or access, catalog the permissions models each one uses, and map who currently has access to what. This is archaeology, and it is necessary. The output of this phase is a rough baseline of reality, not a clean model. It will be incomplete. That is acceptable.

Discovery is politically sensitive. Mapping who has what access reveals over-provisioning, shadow access, and accumulated privilege that people have no interest in surfacing. A manager who has been granting ad-hoc access outside any process will not welcome having that access documented. An engineer who accumulated production permissions over three years of incident responses will not want those permissions reviewed. This phase requires executive sponsorship, because the findings will make people uncomfortable.

Import as Baseline

Take the current state, messy and imperfect as it is, and express it in the declarative configuration format. Do not try to clean it up. Do not try to idealize it. The initial configuration is a photograph of the current state, not a vision of the desired one. Commit it. This baseline is the starting point for all future improvement.

The import is not neutral. Photographing the current state means recording decisions that were wrong or expedient. People will resist having their ad-hoc access documented because documentation implies it might be taken away. The answer is that import is not judgment. The configuration records what exists, not whether it should exist. Cleanup comes later, through the normal review process, with the same approval and audit trail as any other change.

Reconcile in Observation Mode

Enable continuous reconciliation in observation-only mode: detect drift and report it, but do not correct it automatically. This teaches the organization what drift looks like, how often it occurs, and which systems are the worst offenders. It also validates that the integrations work before they start making changes. Run in this mode until the team is confident in the data.

Tighten to Enforcement

Once the reconciliation data is trusted, begin enabling automatic correction: first for low-risk systems, then progressively for more sensitive ones. Each step tightens the loop. Each step reduces the window between drift and correction.

There is no formula for when to switch. The team needs enough reconciliation cycles to understand the false-positive rate, the drift patterns, and the failure modes of each integration. Premature enforcement can revoke access that was needed; delayed enforcement leaves known drift uncorrected. The judgment is human. The manifesto can describe the destination but not the speed limit.

Iterate on the Model

With enforcement active, the model itself can be improved: consolidating redundant roles, introducing composable building blocks, adding temporal constraints, separating definition from assignment. The model evolves inside the same system that enforces it. Each improvement is a reviewed, approved, versioned change.

Many organizations will adopt declarative access for some systems before others. This is not a temporary state — it is the steady state for most organizations. An entity that has integrated twenty of thirty systems manages access declaratively for twenty systems and manually for ten. The configuration can express both states. The audit trail reflects both. The ten unmanaged systems are tracked explicitly, not silently ignored. There is no requirement to integrate all systems simultaneously: only a commitment to expand coverage over time and an honest accounting of what remains outside the model.

The goal is not perfection on day one. The goal is a system that improves monotonically: better tomorrow than today, day by day, without backsliding.

What This Replaces

The traditional model of identity management was designed for a world of single systems and physical access. It has been stretched far beyond its design limits, and the consequences are visible in organizations that operate at scale:

Access requests take days because they pass through queues of humans who interpret, approve, and execute them manually. Onboarding is slow and inconsistent because each system is provisioned independently. Offboarding is incomplete because there is no single place that knows each system a person could access. Permissions accumulate over years because revocation depends on someone remembering. Audits are painful because the evidence is scattered across dozens of admin consoles. Compliance is performative because the documentation diverges from reality the moment it is written.

Declarative Access replaces this with a model where identity is defined in code, changes are reviewed and approved before they take effect, automation handles execution across all systems, and the complete history is embedded in the workflow.

The principles in this document are not theoretical. They are drawn from the same practices that transformed infrastructure management from a manual, error-prone craft into a reliable, auditable engineering discipline. The tools and platforms are different. The principles are the same.

Access is a broad category of organizational technical debt that few measure. The interest is paid in audits, incidents, and lost time. The principal grows with each hire, each new system, each shortcut taken under pressure. These factors describe how to stop accumulating it.