Should organisations separate access certification from remediation for AI agents?

Why certification and remediation need different control paths for AI agents

access certification is a governance decision, it asks whether an AI agent should still have a permission. Remediation is an operational change, it updates the live entitlement, token, or credential state. If one workflow both reviews and enforces, the agentic system can act faster than human intent, which defeats the point of the review.

That separation matters because AI agents often operate on delegated authority and can move from “reviewed” to “changed” in the same execution path. In practice, certification should produce an approved or rejected decision, while remediation should be a bounded enforcement step with its own approval, logging, and rollback path. The control objective is to preserve human judgment over access, not to let the runtime immediately rewrite it.

For AI agents, the right design is usually to treat certification as evidence gathering and decisioning, then hand off only the approved deltas to an enforcement mechanism that cannot reinterpret the decision. That preserves auditability and prevents a tool-using agent from collapsing governance, approval, and execution into a single action.

What goes wrong when the same agent both reviews and fixes access

The main failure mode is review-execution coupling. If the same agent can inspect access, decide that access is excessive, and remove it immediately, then the review record no longer proves that a human or separate control actually approved the change. That creates an integrity problem in the access governance process and makes exception handling harder to trust.

A second failure mode is timing drift. Certification often runs on a schedule, while remediation acts on the current state. If an agent is allowed to mutate permissions during the review window, it can invalidate the sample being certified or create false confidence that access was reviewed before the change. Separation keeps the evidence set stable long enough for the decision to be meaningful.

There is also a blast-radius problem. AI agents commonly have access to multiple systems, so a remediation action can propagate beyond the original certification scope if the agent has broad tool access or shared credentials. Keeping review and enforcement distinct limits the chance that one automation path can both justify and execute a high-impact access change.

How to structure the workflow so approval and enforcement stay independent

Use a two-step pattern: first, a certification record that states what access exists and whether it should remain; second, a remediation job that consumes only the approved decision and applies the live change. The remediation job should not be able to revise the certification outcome, and the reviewer should not have direct write access to the target entitlement store through the same workflow.

For AI agents, the cleanest implementation is to make the certification step read-only and to route remediation through a separate policy enforcement point with explicit scope, expiry, and traceability. That way the agent can recommend removal or reduction, but it cannot silently convert its recommendation into an immediate state change without a distinct control boundary.

Where possible, keep the evidence object, the approval object, and the change object separate. A reviewer should be able to say “remove this access,” while the enforcement system should only be able to say “this approved change was executed at this time.” That distinction is what makes later audit, exception review, and rollback credible.

Risk and Threat Considerations

When certification and remediation are fused, the access review can become self-fulfilling: the same agent that evaluates privilege can also erase or alter the evidence that it evaluated. That weakens governance and creates a path for unintended or malicious overreach in the access layer.

Failure mechanism: A privileged agent, connector, or workflow takes the review decision as both input and authority for enforcement, so a single tool action can change the live entitlement state without an independent approval boundary.

Impact: Organisations can lose audit integrity, over-remove legitimate access, miss exception handling, or allow an abused agent path to make access changes faster than reviewers can detect or stop them.

Practitioner Guidance

What to verify: Check that certification outputs are immutable decisions or tickets, not executable instructions with direct write privileges. If the same pipeline can both approve and apply the change, treat that as a control design flaw rather than a convenience.

What good looks like: The reviewer can approve, reject, or defer access, but a separate remediator performs the state change and records the before-and-after entitlement. For AI agents, that remediator should have the minimum scope needed to execute only the approved delta.

Common mistake: Allowing “auto-remediation” for efficiency without a hard boundary between decision and enforcement. That shortcut is especially risky when the agent has delegated authority, because speed amplifies the consequence of a bad decision.

Practitioner takeaway: Separate the authority to decide from the authority to change, then verify that no agent, workflow, or token can cross that boundary in the same transaction.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• How should security teams govern API keys used for generative AI access?
• How should organisations use AI agents in access reviews without losing governance control?
• Should organisations use JIT access for service accounts and AI agents?