Self-service accessAsk for access. Get a pull request.
People request access to your platforms themselves. Owners approve or deny the pull request. GitOps applies it, and Git keeps the record.
Any platform that maps groups from your identity provider. Microsoft Entra ID today. Using another identity provider? Tell us which one in the waitlist form.
MoreThanOps uses your email to contact you about early access. Optional fields help us size demand. Details and your rights: Privacy.
web-platform
Approve
by MoreThanOps
The problem
Managing access isn't new. But in many teams it's more complex and fragile than it should be: a heavy operational load, and a single request can take days, weeks or even months. Four pains keep coming back.
The information exists, but it's scattered across tickets, emails, approvals and each tool's real configuration.
Answering "who has access to what, why and since when?" means rebuilding it from several sources for every audit.
People who need access wait for approvals, chase owners and open extra tickets. Access becomes a blocker.
Meanwhile the platform or security team applies every grant by hand, and that grows with every hire and every tool.
Access granted for a one-off need is rarely reviewed or removed once it's no longer needed.
Over time, inherited, excessive or ownerless privileges pile up, and memberships added directly in a tool go unnoticed.
Every tool has its own portal, flow and owner. Changes are applied by hand, with different criteria.
It all depends on specific people, and offboarding means visiting every tool and hoping none was missed.
Teams that run infrastructure with GitOps already have a better pattern: a reviewed diff, an author, a reason and a revert. Access is usually the one thing still done by hand.
The solution
The GitOps principles line up with each of those pains. Entitlements as Code applies them to who has access to what.
You define the desired state in files, not the steps to reach it. The tool compares it with the real state and applies the difference.
Every change is a Git commit that records who made it, when and why. Collaboration is easy, and you revert if something goes wrong.
Once a change is approved in Git, the tooling picks it up and applies it. No manual step between approval and execution.
The system checks that the real state matches Git. When they differ, it detects the drift and acts to correct it.
What it is
Review, approval, history and automation for who has access to what. In practice: the GitOps method, applied to access.
The principles it brings
The permissions and access each person has: which projects they can enter, with which role, on which platforms. In practice, a user's membership in groups.
Managing who has access to what the same way you manage code: every change is a reviewed pull request with an author and a reason, checked before review, applied by GitOps and watched for drift.
Microsoft Entra ID: users, guests, groups and memberships. Through those groups, people get their roles inside each connected tool.
How it works
Here is one access request, end to end. Nobody opens an admin console.
Pick the tool, project and role in the portal and say why. That opens a pull request with you as the author.
Eight checks run before anyone looks at it. The owner approves or denies. Your own vote doesn't count.
After the merge, GitOps applies the change in Entra ID and the tool. A drift check confirms nothing changed outside Git, and the optional enforce mode reverts any change made by hand.
Applied by GitOps after approval. ArgoCD can sync on merge, or you keep a manual sync as an operator gate. Rollback is reverting the PR. Prefer chat? Ask in plain English in Claude Code and get the same pull request.
What changes
Requesting access becomes each person's own job. Your team reviews and decides, and the record keeps itself.
Every grant is a PR with the requester as commit author, a written reason, the reviewer who merged it and a date. Who has access to what, why and since when is a question for the Git history.
Requesters pick from a catalogue in a web portal with Entra sign-in, preview, give a reason and follow it under "My requests". They don't need to know Git, and nobody waits for a manual apply.
Every membership lives in Git with its reason and history, so unexplained access is easy to spot. Removing access is a PR or a revert. Offboarding removes someone from every group in one PR.
The same request, review and apply flow and the same eight checks for every connected tool. Typos, badly named groups and group cycles fail before anyone reviews them.
Drift detection shows grants made outside Git and, on Team and Business, can open a PR that brings them into Git for review. With the optional enforce mode, they are reverted instead. Start in read-only observe mode and switch on enforce one Azure DevOps organization at a time. The validation gate also flags sensitive groups with no owner.
Export what already exists with eac bootstrap export, run in observe mode with zero writes, then switch to active one component at a time.
Core + modules
A module maps the same access model to each tool's own permissions. Azure DevOps is the included reference module. For any other platform you need, we build or adapt the module for you as a separate service.
Tell us which platforms you need in the waitlist form, and we'll tailor the first conversation to them.
CoreAccess model in Git · Entra IDCoreSame flow, same checksPricing
Self-hosted. The core will be open source (MIT), and it isn't public yet. Paid plans add the self-service portal, drift auto-PR and support.
The core will be open source, for teams happy to work from the CLI. It isn't public yet.
The open-source core will include:
For teams that want people to request access themselves.
For larger directories that want help rolling it out.
A module built or adapted for one platform with an API that you need, with 3 months of fixes included. Not part of any plan.
Planned pricing for business use, in USD. It may change at launch. Prices exclude VAT. Paid plans aren't open yet: choosing one adds you to the early-access list. The open-source core isn't public yet: choosing Community adds you to the list to hear when it is.
FAQ
Users and groups come from Microsoft Entra ID. Azure DevOps is the included reference module. For any other platform with an API, a module is built or adapted for you through the Custom module service. Tell us what you use in the waitlist form.
Yes, once it's approved. After the merge, ArgoCD and Crossplane apply the change to Entra ID, and the tool's roles follow from the groups. If you want an operator gate, keep ArgoCD on manual sync. Either way, nobody edits an admin console, and rollback is a revert.
No. They use the web portal with Entra sign-in (Team and Business), or ask in plain English in Claude Code. People who prefer the terminal can use the CLI. Every route produces the same reviewed pull request.
No. Today every grant is visible in Git with its owner and reason, removing access is a PR, offboarding is one PR, and drift detection catches grants made outside Git. Periodic reviews and automatic expiry are not part of the product.
A Kubernetes cluster with ArgoCD and Crossplane, a Microsoft Entra ID tenant with an app registration, and a Git repo for the access files. It's self-hosted: your access history stays in your Git and your cluster. We're onboarding the first teams personally.
No stored machine credentials. ArgoCD, Crossplane, the scheduled jobs and the portal's directory reads hold no personal access token or client secret: each one exchanges its Kubernetes identity for a short-lived Entra ID token. The only secret left is the one the portal uses for its own sign-in.
The core will be released under the MIT licence. It is not public yet: we're packaging it into one clean install path first. Join the list, or pick Community in the pricing section, and we'll tell you when you can download it.
Yes, once it opens. A discovery export writes what already exists into YAML, and observe mode reads your directory with zero writes. When you're ready, switch to active one component at a time. Join the waitlist and we'll tell you when you can start.
Early access
Join the waitlist for early access. Tell us which platforms you manage, and we'll tell you what we can connect for you.
by MoreThanOps