Resource Access Certifications for AI Agents vs Keycloak

Last updated: September 2026

An access certification is a recurring review that asks a named human to confirm, or revoke, every permission a given identity holds. Okta made Resource Access Certifications generally available for AI agents at Oktane on 22 September 2026, which puts the campaign workflow inside its Okta for AI Agents line, a separately licensed product rather than something that arrives with core SSO. Keycloak has no equivalent packaged workflow, and it does not need one for you to run the control: what it gives you is a set of reviewable objects and an exportable event stream, so the certification becomes a quarterly job you own rather than a SKU you buy.

That distinction is the whole decision. If you are shopping for identity governance and administration because an auditor asked how agent permissions get reviewed, you are choosing between buying the campaign machinery and building a thin version of it around objects you already have. Both are defensible. What is not defensible is registering an agent once, granting it the access it needed that week, and never looking again, which is where most deployments are today.

What did Okta actually ship, and what does it cover?

Okta announced at Oktane on 22 September 2026 that Agent SSO, Agent-to-Agent Connections and Resource Access Certifications are generally available, as part of its Okta for AI Agents line (Okta, “New Okta for AI Agents innovations increase visibility into agent behavior, secure connections at runtime, and enforce continuous agent governance,” newsroom press release, 22 September 2026). Resource Access Certifications is the governance piece: it reviews the connections between an agent and the resources it can reach, over time, so standing and excessive permissions get caught by a cadence rather than by an incident.

Two things are worth separating here, because vendor announcements blur them. The technically interesting part is that agent-to-resource connections became first-class objects, which is what makes them certifiable at all. The commercially interesting part is the campaign workflow around those objects: owners, due dates, reminders, an audit record of who confirmed what. The first is a data model decision. The second is the product, and it is genuinely tedious to build.

Okta’s own access certification documentation for human users predates the agent variant, so the mechanics are familiar to anyone who has run an IGA campaign. What is new in 2026 is pointing the machinery at non-human identities, whose access changes faster and whose owners are harder to name.

Why does an AI agent need an access certification more than a human does?

Because the usual safety net does not exist. A human’s access gets reviewed by accident: they change teams, a manager notices, HR triggers an offboarding, somebody asks why they still have production. An agent has none of those events. It is created by an engineer during a sprint, granted whatever scope made the demo work, and then it runs. Nothing about an agent generates the social friction that eventually surfaces over-permissioned humans.

The failure mode is specific. An agent gets a service account with broad read access “for now,” ships, and becomes load-bearing. Six months later nobody remembers which of its twelve permissions it actually calls, the engineer who created it has moved teams, and the only safe action is no action. That is standing privilege by inertia rather than by decision.

What we see in practice: the hard part of agent governance is almost never the revocation. It is naming an owner. Deployments that can answer “who signs off on this agent’s access” in one lookup can run a review in an afternoon. Deployments that cannot will fail the review no matter which product they buy, because a certification campaign with no reviewer is a ticket that ages.

Registration-time approval, which is what most teams have, answers a different question than certification. Registration asks whether this agent should exist. Certification asks whether what it can reach today is still what it needs. We worked through the discovery half of this problem, finding the agents nobody registered, in shadow AI agent discovery; this post assumes you know what exists and are now being asked to justify it.

Which Keycloak objects can you actually certify?

Everything an agent’s access is made of, if you model the agent as a client rather than as a user. On Keycloak 26.x that gives you a short list of reviewable objects, all readable through the Admin REST API and therefore all diffable between quarters.

The one-client-per-agent rule is what makes this tractable. It is also the recommendation we keep repeating, for a reason that shows up exactly at review time: a shared service account cannot be certified, because there is no per-agent answer to give. Every agent behind it has identical permissions and indistinguishable logs. Our comparison of non-human identity to plain service accounts goes through the setup itself.

Where an agent acts for a named human rather than as itself, standard token exchange under RFC 8693 has been officially supported since Keycloak 26.2, and it is worth being exact about what it does. It swaps the audience while keeping the same subject, so the token the agent presents downstream still names the human. What it does not do is actor-chain delegation: the standard exchange rejects requested_subject, and the separate Token Exchange Delegation feature is still marked experimental in 26.7.4. For a review that distinction cuts the right way, because a token that still names the human makes “is this person’s access still appropriate” the question, which is far more answerable than whether a broad service-account scope is still appropriate. The underlying pattern, and where it stops, is in our writeup on cross-app access and ID-JAG.

How do you run an access review on Keycloak without an IGA product?

Four moving parts, none of which require software you do not have. We will not pretend this is as comfortable as a campaign dashboard.

Record an owner at creation time, and refuse to create agents without one. A client attribute holding a human’s identifier, set by whatever provisions your clients, is the single highest-value thing on this list. It is also the step teams skip, then spend the review reconstructing from git history.

Export the current state on a cadence and diff it against last quarter. The Admin REST API gives you clients, scopes, mappers and role mappings as JSON. A scheduled export into version control turns the review from an interview into a code review: the reviewer reads what changed since they last approved, not the entire realm. Quarterly suits most regulated programs; monthly suits agents that touch customer data.

Set an expiry that bites. A certification that has no consequence for non-response is a reminder email. Practical options on Keycloak are short token lifespans for agent clients, so access depends on continuously working credentials rather than on a forgotten grant, and a documented policy that an agent whose owner does not confirm within the window gets disabled rather than escalated.

Know exactly what revocation does, in order. This is where the sharp edge is, and it is worth stating precisely because it surprises people mid-incident:

1. Disabling the client stops new tokens being issued for it.
2. Revoking its sessions, including offline sessions, clears what is stored server side.
3. Rotating the client secret stops anything holding the old credential from coming back.
4. Access tokens already issued remain cryptographically valid until they expire, and a resource server doing local JWT validation will keep accepting them.

Step four is the one that decides your token lifespan policy. If your APIs validate tokens offline, a five-minute access token means revocation is effective in five minutes and a one-hour token means it is effective in an hour, whatever the admin console now shows. We hit a sharper version of this same gap in CVE-2026-93999, where refreshing restored a disabled audience client, and the lesson generalizes: client state is checked when tokens are minted, not when they are used.

What evidence does an auditor actually accept?

Records with three properties: what access existed, who confirmed it, and when. The framework language is less specific than engineers expect. ISO/IEC 27001:2022 Annex A control 5.18 covers access rights, including their periodic review; NIST SP 800-53 Rev. 5 carries account management under AC-2 and review of privileges under AC-6(7); SOC 2’s CC6 series covers logical access without prescribing a tool. None of them names a product, and none of them distinguishes human from non-human identities in a way that would let you exclude agents.

What that means in practice is that a dated export, a named approver, and a revocation record satisfy the control. A screenshot does not, and neither does an assertion that reviews happen. The one capability worth building before your first audit rather than during it is getting events out of the cluster, since Keycloak’s event store is not an evidence archive; forwarding events to a SIEM or log platform gives you the retention an auditor asks for, and audit logging is where the record starts. If you want the wider workflow view, including approvals for human access requests, our identity governance workflow guide covers it.

Our finding: the audit question that most often fails is not “do you review agent access” but “how do you know that list is complete.” A review of the agents you registered says nothing about the ones running on personal API keys. Pair the certification with discovery, or you are certifying a subset and calling it a population.

When is buying the certification workflow the right call?

When the campaign is the work. Three situations make a purchased workflow clearly better value than the discipline described above: you are certifying across many systems rather than one identity provider, so the reviewer needs one queue instead of six; you have non-engineer reviewers who will not read a JSON diff; or your auditors want the reminder-and-escalation trail as evidence, not just the outcome. That is the honest case for an IGA product, and an identity provider is not one. Keycloak is the place agent permissions live, not a governance suite, and treating it as one produces a spreadsheet nobody maintains.

The case for keeping it in your own hands is equally practical. Your agents are probably concentrated in one realm, your reviewers are the engineers who own the services, and the objects are already machine-readable. The review then costs a scheduled export and an hour of somebody’s quarter, with no per-identity governance pricing attached to agents that may multiply faster than your headcount does.

Where does managed Keycloak fit in this?

It removes the reason most teams never start. Skycloak is identity management as a service built on upstream Keycloak, so the objects in that table above are the upstream objects, with the cluster, the patch cadence and the event pipeline run for you. The review discipline stays yours, because nobody outside your organization can tell you whether a given agent still needs write access to billing.

Where it changes the arithmetic is on the day-2 work around the review: having audit events already flowing somewhere with retention, having a staging realm to test a revocation against, and not having the quarter’s security upgrade compete with the quarter’s access review for the same engineer. Teams evaluating this alongside the wider agentic feature race may want our read on what Okta, Ping and JumpCloud announced this year, which covers the runtime controls rather than the governance ones.

FAQ

What is an access certification?
A recurring review in which a named owner confirms or revokes each permission an identity holds, producing a dated record of the decision. It differs from access request approval, which happens once at grant time. Frameworks including ISO/IEC 27001:2022 Annex A 5.18 and NIST SP 800-53 AC-6(7) expect the periodic version, not just the initial grant.

Does Keycloak have access certification campaigns?
No. Keycloak 26.x has no campaign workflow, reviewer queue or attestation record as a built-in feature. What it has is the reviewable objects, clients, client scopes, role mappings and fine-grained admin permissions, all readable through the Admin REST API, plus an event stream you can export. The cadence and the record are yours to run.

How often should AI agent access be reviewed?
Quarterly matches most regulated programs and is what we would default to. Move to monthly for agents that reach customer data or hold admin permissions. The interval matters less than whether non-response has a consequence: a review that cannot disable an unconfirmed agent is documentation, not a control.

Can I certify agent access without naming a human owner?
Not usefully. Every certification ends in a person accepting risk, so an agent with no owner produces a review nobody can complete. Record the owner as a client attribute when the client is created. Reconstructing ownership afterwards from commit history is the single most expensive part of a first review.

Is a shared service account ever acceptable for multiple agents?
Not if you have to certify it. Shared credentials make revocation all-or-nothing and make logs indistinguishable between agents, so there is no per-agent decision for a reviewer to make. One confidential client per agent costs almost nothing in Keycloak and is what makes both the review and the revocation possible.

Sources

• Okta, “New Okta for AI Agents innovations increase visibility into agent behavior, secure connections at runtime, and enforce continuous agent governance,” newsroom press release, 22 September 2026, retrieved 2026-09-23, https://www.okta.com/newsroom/press-releases/ai-innovations-oktane-2026/
• SiliconANGLE, “Okta adds AI agent runtime gateway, forms Blueprint Alliance with AWS and CrowdStrike,” 22 September 2026, retrieved 2026-09-23, https://siliconangle.com/2026/09/22/okta-adds-ai-agent-runtime-gateway-forms-blueprint-alliance-with-aws-and-crowdstrike/
• Okta, “Access Certifications,” Okta Identity Governance product documentation, retrieved 2026-09-23, https://help.okta.com/oie/en-us/content/topics/identity-governance/access-certification/iga-access-cert.htm
• Keycloak, “Standard Token Exchange is now officially supported in Keycloak 26.2,” May 2025, retrieved 2026-09-23, https://www.keycloak.org/2025/05/standard-token-exchange-kc-26-2
• IETF, “OAuth 2.0 Token Exchange” (RFC 8693), retrieved 2026-09-23, https://datatracker.ietf.org/doc/html/rfc8693
• Keycloak source, Profile.java (feature types for TOKEN_EXCHANGE_STANDARD_V2 and TOKEN_EXCHANGE_DELEGATION) and StandardTokenExchangeProvider.java, tag 26.7.4, retrieved 2026-09-23, https://github.com/keycloak/keycloak/blob/26.7.4/common/src/main/java/org/keycloak/common/Profile.java
• ISO/IEC 27001:2022, “Information security, cybersecurity and privacy protection: Information security management systems,” Annex A control 5.18 Access rights, retrieved 2026-09-23, https://www.iso.org/standard/27001
• NIST, “Security and Privacy Controls for Information Systems and Organizations” (SP 800-53 Rev. 5), controls AC-2 and AC-6(7), retrieved 2026-09-23, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final