Teams running or considering Keycloak who now need to authorize agent tool calls.
Whether to replace Keycloak, extend it, or put a decision layer in front of the tools it protects.
The control gap
Keycloak is usually chosen for control: your own deployment, your own realms, no per-user pricing. Those reasons do not disappear when agents arrive. What does appear is a set of questions Keycloak was not designed to answer per request. Which of these two calls to the same endpoint should be denied because of its arguments. Which one needs a human. What the reviewer saw when they approved it. Those are decision and evidence problems, not issuance problems.
What good looks like
Keycloak keeps issuing and validating tokens, and a separate decision point evaluates each tool call with the arguments and the resource in view.
- Keep the authorization server where it is if it works. Migrating issuance is expensive and does not answer the agent question.
- Add a decision point at the tool boundary that receives the agent, the delegated user, the action, the resource, and the arguments.
- Express high-impact actions as explicit deny or approval rules rather than as scopes, since a scope cannot see an amount or a target.
- Keep the decision record separate from the access log, so an approval and its execution stay linked.
A production workflow
- Continue authenticating agents and users through the existing realm.
- Pass the resulting identity into the decision point as context rather than as authority.
- Evaluate the concrete call, allow, deny, or hold for approval.
- Execute only on an allow, and attach the outcome to the decision that permitted it.
Evidence to require
- The realm, client, and user behind each agent action.
- The action and resource evaluated, including the arguments that made it high-impact.
- The rule that matched, its version, and the reason recorded.
- Approvals with reviewer, expiry, and whether the approved call actually executed.
Buyer checklist
- What is genuinely missing: issuance, per-object permissions, or per-call decisions?
- Can the current setup deny one call and allow another when both use the same client and scope?
- Is there a human approval path today, and where does its record live?
- What would a migration of issuance actually buy, measured against its cost?
Practical answers
Common implementation questions
Is Endram a Keycloak replacement?
No. Endram does not manage realms, federate identity providers, or replace an authorization server you already run. It is a decision and approval layer for agent tool calls that sits in front of the systems those tokens reach.
Keycloak has authorization services. Is that not enough?
It handles resource and permission modelling well for application resources. What it does not do is inspect the arguments of an agent's tool call, pause it for a named reviewer, and keep an execution-bound receipt, which is what agent workflows need.
Does adding a decision layer mean two places to configure permissions?
Yes, and that is a real cost. The split that works is coarse boundaries in the identity platform and per-action rules at the tool boundary, with each layer owning what it can actually see.