Keymate

Authorization Governance

Authorization governance controls how access policies change and proves what they decided. In Keymate, every policy change is versioned, tested against past decisions before it goes live and can be rolled back, and you can require an approver. The decision log records who did what, when and under which policy version.

The audit question

When an auditor asks who could access what, and who approved it, the answer is usually spread across application code and spreadsheets.

  • Banking

    "Who can edit payment records, and who approved that?"
  • Healthcare

    "Who can see patient files outside their own ward?"
  • B2B platform

    "Which partner admins can invite users into a tenant, and since when?"

The Keymate admin console answers each of these with the trail attached: the policy, the condition, any approver, and every decision it produced.

A policy change, governed end to end

  1. 1Draft. Write the rule in the policy editor.
  2. 2Simulate. Test it against real past decisions.
  3. 3Approve. If you require it, a second person approves the change.
  4. 4Publish. It goes live the same day, with no app release.
  5. 5Roll back. Return to any earlier version in one step.
Version history of an authorization manifest in the Keymate admin console, with the difference between two versions

What Authorization Governance includes

  • Decision explainability

    For every deny, Keymate shows why access was denied: which policy decided, which condition failed and what would change the outcome.

  • Policy change simulation

    Do a dry run of a change against real past decisions before it goes live, and see which decisions it would change.

  • Evidence and audit trail

    Decisions are kept in an immutable store, with personal data masked. Audit reports are built from these records.

  • Time-bound access

    Access for a set period, approved with its end date. On that date the access ends on its own.

Evidence an auditor can use

Every decision is recorded with the user, the resource, the action, the time and the policy version, and any approval behind it. The records stay on your infrastructure, and any decision can be replayed later. Access evidence for audits shows what an auditor receives.

evidence ▸ your auditor

in minutes

Further reading

Questions

Is this a separate product?

No. It is one of the Keymate modules: the same console and the same policies, with approvals, simulation and evidence added. Pricing shows what each edition includes.

Does it require the Keymate decision engine?

No. It works with Keymate's decision point, and a different decision engine can be plugged in instead. The change cycle and the evidence trail work the same whichever engine makes the decision.

What is authorization governance?

Authorization governance is the control of how access policies change and the proof of what they decided. It covers who may change a policy, who approves the change, how its impact is tested first, how it is rolled back, and the record of every decision the policy produced. Identity governance asks who has which access; authorization governance asks how the rules behind that access are changed and proved. The Identity Governance page shows how the two modules fit together in Keymate.

How do I version, approve and roll back access control policies?

Give each policy a lifecycle: draft it, test it against past decisions, approve it if you require approval, publish it, and roll it back when needed. In Keymate every version is kept with its author and the exact lines changed, and a version that has gone live is never rewritten. All of this happens in the Keymate admin console, so a new version or a rollback never waits for an application release.

How do we govern authorization policy changes with approvals?

Require an approver before a change reaches production. In Keymate you can turn this on for every policy, and the approval is stored with the policy version, so the change and its approval are one record.

How do I answer "who can do what" across multiple Keycloak instances?

Answer it from one evidence store instead of an export from each instance. When access decisions for all your applications go through Keymate, every allow and deny lands in that store, with the user, the resource and the policy version, so "who can do what" is answered from one place. Access evidence for audits shows the reports.

What tools provide authorization governance?

A tool provides authorization governance when it gives four controls: an approval step you can require before a policy goes live, a dry run of the change against real past decisions, rollback to any version, and a decision record tied to the policy version in force. These controls sit between authorization engines, which decide access, and identity governance suites, which review who holds which access. Keymate provides all four in its Authorization Governance module. The Keymate IAM platform comparison sets several platforms side by side.

Which IAM platform gives me policy approval workflows and an audit trail, self-hosted?

Look for a platform that runs on your own infrastructure and gives you three things: an approval step you can require for policy changes, a kept history of every policy version, and a record of every allow and deny with the policy version and any approval behind it. Keymate meets these checks: its approval workflow, version history and evidence store all run on your infrastructure, air-gapped if you need it (Enterprise). The Keymate IAM platform comparison sets several platforms side by side.

See a policy change made, versioned and recorded.