The principles of Entitlements as Code

The principles describe a way of working, not a tool. A team can follow them with a few scripts, with a product, or with both. Each one below says what it means, why it matters, what it looks like day to day, and the habit it replaces.

1. Git is the source of truth for access

The principle. Who holds which entitlement is written down in Git, in files people can read: one file per group, with its members and its owners. The platforms are made to match the files, not the other way round.

Why it matters. "Who has access to what, and since when?" gets one answer, with its history. Nobody has to rebuild it from admin screens and exports before an audit.

What it looks like. A repository with a folder per organization and a file per group. Reading a file tells you who is in the group today; reading its history tells you who was, when they joined and who approved it.

It replaces access that only exists in each tool's admin screen, and the spreadsheet rebuilt every year to describe it.

2. Every change is a reviewed proposal

The principle. Access changes the way code changes: someone proposes a change, someone else reviews it, checks run, and only then is it merged. The pull request records the author, the reason, the exact change, the approver and the date.

Why it matters. The approval and the change are the same object. There is no gap between "the ticket was approved" and "what was actually done", and undoing a change is a revert.

What it looks like. A request to join a group opens a pull request that adds one line to that group's file. Automated checks flag naming problems, sensitive groups without an owner, or a request that breaks a rule, before anyone approves it.

It replaces tickets that say someone asked, while the change itself is done by hand somewhere else and leaves no trace.

3. Owners decide, and nobody approves their own access

The principle. Every group has owners, and the owners of a group approve who joins it. The person asking never counts as an approver, and neither does anyone who edited the request or anyone who gets the access. A change of owners needs two different people, because owners decide who gets in.

Why it matters. This is separation of duties applied to access. An approval only means something if the person who gave it could not benefit from it, and if they know the group well enough to judge.

What it looks like. The owner of a group gets the request, sees who asks, why and until when, and approves or declines it. Administrators keep the platform running; they do not approve access to every group.

It replaces a central team that approves everything it does not know, and approvals that the requester can give to themselves.

4. People ask for what they need

The principle. People ask for access themselves, for a specific group, with a reason and an end date. Groups are small and named after what they give, so asking for the right access is easier than asking for broad access.

Why it matters. The person who needs the access knows why. Writing the reason and the end date at the moment of asking costs seconds, and it is what reviewers and auditors need later.

What it looks like. A short form or a pull request: the group, the reason, the date the access should end. The request goes straight to the group's owners.

It replaces "give me the same access as Ana", which copies every grant a colleague collected over the years.

5. Access ends when it is no longer needed

The principle. Access has a lifecycle. Grants carry an end date when they are temporary, owners review who keeps access on a schedule, and removing access is a change like any other: proposed, approved and recorded.

Why it matters. Least privilege is not a state you reach once; access piles up unless something removes it. End dates and reviews are what keep the record small and true.

What it looks like. A grant with an end date is removed on that date by a pull request. Each review lists the members of a group, the owner keeps or removes each one, and each removal is a recorded change with a reason.

It replaces access that lasts until someone happens to notice, and yearly reviews in spreadsheets that do not change anything.

6. Platforms follow the record; anything else is drift

The principle. What the platforms show is compared with Git all the time. A difference is drift: a member added by hand, a member removed by hand, a group that Git does not know about. Drift is either reported for a person to decide, or put back to what Git says.

Why it matters. People with admin rights will always be able to change access directly, during an incident or as a favour. The record only stays true if those changes are seen.

What it looks like. A drift report that lists every difference, and, where the team has chosen to enforce, changes made by hand that go back to what Git says without anyone asking.

It replaces emergency grants that stay forever because nobody knew they were there.

7. Adopt it step by step: observe before you enforce

The principle. Start from the access that exists today. Import it into Git, then observe with nothing written: people ask and owners approve, and differences are only reported. Enforce one organization at a time, when its owners and its files are ready.

Why it matters. If a new process enforced wrong files on day one, every mistake would become a change in someone's access. Observing first finds those mistakes while they are still harmless.

What it looks like. One organization enforces while another keeps observing; switching an organization to enforce is itself a reviewed change.

It replaces a big-bang switch that breaks access on a Monday morning, and the loss of trust that follows.

Where to go next

• Where Entitlements as Code comes from: the ideas these principles borrow from engineering and from identity governance.
• The framework: the lifecycle of a grant and the capabilities that put the principles to work.
• In practice: how it looks on Microsoft Entra ID and your platforms, with your own tools or with a product.