RiskMandate v1.34.4
The business case · Identity

Keycloak, by the risk it changes

An identity and access management server. Its standard token exchange lets a client exchange a token issued for one client for a token aimed at another, carrying the identity of the party on whose behalf the request is made. Written as an answer, an agent acting on a token that starts from a named person's login acts as that person, not as an ownerless service account.

Open source: Apache-2.0 · CNCF (incubating) · get involved

The deployment: The model's typical deployment, with the answers this project addresses stated as they are without it: it acts under a service account nobody owns.

The model: the RiskGraph Explorer's 49 facts, 49 risks and 10 roles, copied into this site with its provenance; the register below is computed, not written. How.

01 · What it does

In its own words, and nothing more.

  • Standard token exchange within a realm. “A client can exchange an existing Keycloak token created for a specific client for a new token targeted to a different client in the same realm.” · www.keycloak.org, read 24 September 2026
02 · The answers it changes

Same deployment, different answers.

The model asks sixteen questions about an agent deployment. A product’s effect is written as the answers it changes, and each change says what kind of change it is: a statement of what is true, an expectation the agent is asked to meet, a setting, or a boundary enforced by something the agent’s grant does not include.

The questionWithout itWith itHow, and who holds it
Whose account does it act under?A service account nobody ownsA named person'sa setting, held by the deployer. Only when the exchange starts from a named person's token and the systems downstream accept Keycloak tokens. “A client can exchange an existing Keycloak token created for a specific client for a new token targeted to a different client in the same realm.” · www.keycloak.org, read 24 September 2026
03 · The register, before and after

1 retired, 22 unchanged.

Computed from the model for the deployment above: every risk that holds without it, and every risk that holds with it.

1retired
0new
23 → 22entries on the register

Retired

RISK-14
The agent's actions cannot be attributed to a personoperational · CISO, DPO
04 · From the operator to the board

Who carries less, and who carries the same.

Each risk is assigned to the roles it belongs to, and each role reports to another until the board. The count beside each role is the entries it holds without the product and with it.

Operators

who run it, and are paged when it goes wrong
SRE / platform on-call9 → 9
Customer-facing service owner2 → 2

Owners

who own what it may touch, and can say what happened
Platform owner3 → 3
CISO8 → 7 −1retired RISK-14
DPO6 → 5 −1retired RISK-14

Executives

who answer for speed, product, cost and the whole
CTO3 → 3
Chief Product Officer4 → 4
CFO0 → 0
CEO3 → 3

The board

who must be able to defend how it is run
Board4 → 4

At the board: the corporate register

Corporate risks have no facts of their own. They hold while any risk that leads into them holds, so a single product rarely retires one. What it changes is how many reasons the board is being given.

CORP-1
Regulatory exposure — the organisation may be operating outside obligations it is subject tostill holds · risks leading into it: 2 before, 2 after
CORP-2
Customer harm — customers may be affected by decisions or changes nobody madestill holds · risks leading into it: 2 before, 2 after
CORP-3
Operational resilience — the organisation may be unable to restore a service it depends onstill holds · risks leading into it: 1 before, 1 after
CORP-6
Loss of control — the organisation operates a system it may not be able to stop or explainstill holds · risks leading into it: 2 before, 2 after
06 · What it adds

Every product is also a new thing in the estate.

It sits in the authentication path and holds the realm's users and sessions. Its page also says the exchanged tokens in a chain should be revoked, which is a job somebody has to own.

Free, but not free

What adopting it takes, before any of this is true.

An open-source project costs nothing to download and something to adopt. Every change above depends on the work below, and most of it is customisation to your own deployment.

  • Set up the realm, the clients and the exchange permissions.
  • Decide which person each agent acts for, and how that is recorded.
  • Keep delegation off until it is no longer marked experimental, as the page advises.
Where its pages disagree

Published unresolved, for CNCF (incubating) to settle.

Each pair was read on the same day. We have not tested which is true, because that would mean testing somebody else’s system.

  • impersonation and delegation. The capability list includes impersonating a user, while the same page says standard exchange supports only the first use case, calls delegation experimental and not for production, and describes the legacy exchange as a very loose implementation of the specification. token-exchange
What this does not claim

The limits of the case, stated by the case.

  • That it was tested. Nothing was installed or run; every change rests on the documentation quoted beside it.
  • That the register is complete. It is one model, for one stated deployment. A different deployment changes the answers, and so the case.

Next. Published, and sent to the project's maintainers at the same time. If a change is wrong, or another answer should move, the case changes with the date they said so.

The same method, for your product

Make the case in the register’s own terms.

If you build a security product for agents, the case for it can be written the same way: what it does in your own words, the answers it changes, and the register before and after. If a case here is wrong about you, tell us and it changes with a date.

All the casesWrite to us