What lifecycle states does a Keymate policy move through?

Draft, Active, and Disabled. A policy is authored in Draft, enforces decisions once Active, and can be safely turned off without losing its history.

Can an active policy be edited directly?

Not the version that already went live. That exact version is frozen the moment it activates and can never be rewritten, only replaced by a new one. What stays editable is the policy's own source definition, patched in place, not a separate draft object sitting behind it. An edit while Active only takes effect the next time someone activates it.

What happens when a policy is disabled?

Disabling is reversible, and nothing is deleted, so a disabled policy keeps its full version history and can be turned back on. It is not risk-free: removing a policy from evaluation can change what a request gets back right now, depending on how the containing permission combines its policies. The platform already blocks the sharpest version of this risk. A reusable policy cannot be disabled while an active manifest still depends on it, and the error names exactly which manifest is in the way.

How is this different from how Keycloak handles policy by default?

The built-in Keycloak authorization services let you edit a policy directly, live, with no required version history. Keymate adds a policy control plane on top that versions, guards, and logs every change instead.

Why does it matter that an active policy version is immutable?

Because it means the version on record is provably what got activated, by whom, and when, a fixed point to check a live decision against. Whether the live decision still matches that record is a separate, detectable-drift question, not an automatic guarantee.

Authorization Policy Lifecycle: Ship Like Code

Q: Who can see why a policy went live?

Every activation is logged with who made the change and why, success or failure. It also publishes to Keymate's own event integration point, the same one other realm activity uses, so there is no separate system to wire up by hand.

TL;DR

A policy moves through three states: Draft, Active, and Disabled.
Once a policy activates, that version is frozen; changing it means creating a new one, not editing what shipped.
An Active policy can never quietly slide back to Draft. The platform blocks that transition outright.
Every activation is logged with who made the change and why.
Disabling is reversible and keeps full history. Nothing is ever deleted.

When a policy edit is just a save, everyone is one save away from an incident

A policy lifecycle is the states a policy moves through from creation to retirement. Keymate treats that lifecycle as a small piece of software, not configuration you edit in place. A policy change is not real until it is versioned and logged, not the moment you hit save.

Tighten the policy set behind a scope-based approve permission in Keycloak's Authorization Services, and the change takes effect the moment you save it. There is no draft state, no version to point back to, and nothing that captures why. Admin event logging is off by default, and even switched on it tells you what changed, not why, unless a custom listener smuggles a reason in. What you do keep is not permanent either, it ages out with your retention window.

Even "the moment you save it" is not as clean as it sounds. Roles and permissions travel inside access tokens, and for the Authorization Services path the verdict gets baked into the RPT at the token endpoint. A token already in a user's hands keeps enforcing the old decision until it expires, by default after five minutes, or until it is refreshed. A live edit guarantees an eventual effect, not an instant, uniform one.

Most of the time that is fine. Then a permission gets tightened at the wrong scope and an integration starts failing. The first question is not "how do we fix it" but "what did this look like an hour ago, and who touched it." Without an answer, the fix is a guess dressed up as a decision.

Why "how do policy changes ship" is a real diligence question

For an IAM specialist evaluating an authorization platform, this is one of the first things worth checking, and one of the easiest to get wrong. Treating a policy the same way as a feature flag, edit it, save it, done, is the common default, plain Keycloak's built-in authorization services included.

Keymate does not, and why we built Keymate explains the reasoning. A policy here goes through the same controls a production code change does: a version, a guard, and a record, before it counts as live. That difference is often what separates authorization infrastructure a security team can actually sign off on from infrastructure they have to keep watching.

Traditional Keycloak authorization treats a policy change like a light switch

Keycloak's built-in authorization services model a policy as configuration: a resource, a permission, a rule, stored and mutated directly. There is no first-class concept of a draft, no required review step, and no version history tied to the change itself. That is not a defect in Keycloak, just not what the built-in model was designed to do. It is exactly why Keymate ships a dedicated policy control plane on top of it, rather than asking teams to build this discipline themselves, repo by repo.

Inside Keymate's policy lifecycle: a guard that cannot be talked out of it

A policy moves through three states: Draft, while it is being authored, Active, while it is enforcing decisions, and Disabled, when it is turned off without being deleted.

One rule is non-negotiable: once a policy is Active, it can never quietly slide back to Draft. Keymate's policy control plane blocks that transition outright, so a policy's status is never something you have to double-check by reading application state. The label is the truth.

Activation is where the freeze happens, but not the way a simple on-off switch would suggest. What locks is the version that goes live. The moment a policy activates, it gets a permanent, opaque version id, and that specific version can never be edited again. The content hash itself is set earlier, the instant a policy is created. The Git commit that mirrors it comes later and separately, written asynchronously once a background worker catches up, and only if the realm has a mirror configured at all. For policies meant to be reused across manifests, the freeze goes further. Once a version has gone live even once, its content is sealed for good, and that seal survives being disabled and turned back on. Editing something that already shipped never means rewriting what shipped. It means building the next version.

What is missing today is a second set of eyes, not a state. One person can author a policy and activate it themselves, and nothing in the platform stops that yet. The fields an approval step would need already exist, they are simply not wired to anything.

Neither gap looks accidental once you see what shipped instead. Both the freeze and the record work without a second person signing off, so they could ship first and stand on their own. The schema already holds the shape for approval, so what it still needs is wiring rather than a migration.

The Git mirror stayed asynchronous and optional for a narrower reason. Making activation depend on a synchronous commit would tie the policy control plane's correctness to git's availability. The mirror reads more like an export path than a dependency.

Click through the states above and see how a policy moves from Draft to Active to Disabled.

What a policy change earns before it counts as live

A policy change earns real scrutiny before it can be called live, not just a version number. Activation runs a check most systems skip. If the change would delete anything, it only proceeds when the caller echoes back the exact hash of the preview that got reviewed. If the preview surfaces an ownership conflict, activation stops until someone resolves it explicitly. A reusable policy reference has to name a specific version and digest when it is expressed that way, the same discipline a lockfile brings to a dependency tree. And the transition itself cannot be silently walked back: once live, it stays live until someone explicitly disables it.

Then comes the record. Every activation, successful or failed, is written the moment it happens with who did it, why, and what happened, not reconstructed afterward from memory. That record also publishes to Keymate's own event integration point, the same one other realm activity uses, so it does not need a separate system stitched on later.

Where this shows up today

Open a policy in Keymate's Admin Console and this is what is there: the version, the guard, the record, the policy lifecycle made visible. What is provable is what got activated, by whom, and why. Whether the decision a request gets right now still matches that record is a different question. A native edit to the projected policy inside Keycloak's own store is not blocked today, only detectable, and only if a realm has turned that detection on. A security team evaluating this platform will find that gap either way.

For a platform standing between every user and every decision, a provable record of what was activated is not a nice-to-have. It is the baseline everything else builds on.

Series navigation ← Why Keymate? ← The Limits of RBAC ← Multi-Tenancy & Delegation → Authorization Observability and Decision Traces (coming next)

Policy Lifecycle: A Policy Change That Ships Like Code