{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih4wk2p77pivxe33iwwk2et322clr35cipwvlhrm3mpe6yuf4efu4",
    "uri": "at://did:plc:uwj5fyuv3lbhhoybn5hnrqx4/app.bsky.feed.post/3mn37gqxuyjh2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiath2h53n3ev7vp2odgyfqwcehdfuk7ymmphuutfnl5ntcvo4y2gy"
    },
    "mimeType": "image/png",
    "size": 1048561
  },
  "description": "Access-recertification agents should draft and route decisions first, with RBAC, HITL approval, audit evidence, policy checks, and rollback before any low-risk automation.",
  "path": "/how-to-stage-access-recertification-agents-without-turning-reviews-into-rubber-stamps/",
  "publishedAt": "2026-05-30T13:57:52.000Z",
  "site": "https://blog.tuguidragos.com",
  "tags": [
    "Microsoft Entra access reviews",
    "Okta Governance Analyzer",
    "Access Recommendations",
    "NIST concept paper on software and AI agent identity",
    "careful adoption of agentic AI services",
    "OpenPort Protocol"
  ],
  "textContent": "The tempting promise for access-recertification agents is speed. In its 2026 identity governance report, Opal says traditional approval speed is measured in days to weeks, while AI-ready approval can move to minutes or seconds when policy-routed approval engines and automation handle common cases. That headline approval-latency comparison is a single vendor self-reported result and is not yet independently corroborated. Still, it frames the operator question correctly: how can enterprises reduce review drag without training reviewers to click through agent suggestions? The safest answer is to stage these systems as recommendation-and-routing agents first, not autonomous decision systems. The agent should prepare evidence, classify review items, explain keep, revoke, or needs-review drafts, and route work, while humans and policy enforcement retain authority over access-changing outcomes.\n\n## What the Data Shows\n\nThe public IGA product evidence shows that recommendation workflows are no longer theoretical. Microsoft Entra access reviews support recommendations based on signals such as last sign-in or last access, allow reviewers to accept recommendations with a single selection, and let reviewers change responses before completion. Microsoft also documents review-stage controls and optional auto-application of access-removal results. That combination is useful, but it is also where rubber-stamp risk begins.\n\nOkta’s 2026 IGA release notes point in the same direction. Okta Governance Analyzer provides reviewers with insights and recommendations for approving or revoking access, while Smart Review groups campaign items by user or resource. Okta also added assignment-method context and active campaign reporting, which matter because reviewers need to know why access exists, not just whether it resembles a pattern.\n\nSailPoint is explicit about the decision boundary. Its Access Recommendations use peer-group analysis, identity attributes, shared AI core identity attributes, and thresholds to guide certification decisions. The documentation says recommendation icons can indicate whether more than 70% of identities in a peer group have the access, or whether access is unique or held by 70% or fewer peers. It also states that recommendations are guidance only and that reviewers and approvers remain ultimately responsible.\n\n## Where Execution Risk Appears\n\nThe first risk is not model accuracy in isolation. It is decision compression. If a review interface makes a recommendation easy to accept, reviewers may treat the agent’s draft as the default answer even when the evidence is thin. Last-access data, peer similarity, and assignment context are helpful signals, but none of them alone proves that access is appropriate for a user’s current job, current risk, or current policy state.\n\nThe second risk is authority confusion. A recertification agent may read entitlements, summarize evidence, draft decisions, call ticketing tools, and trigger remediation workflows. Each action can carry a different risk level. The 2026 NIST concept paper on software and AI agent identity treats this as an identity and authorization problem, not merely an AI quality problem. It calls out identification, authentication, authorization, auditing, non-repudiation, delegation, logging, and binding agent identity to human authority for HITL authorization.\n\nThe third risk is hidden privilege movement. A poorly staged agent might turn a certification campaign into a chain of access-changing actions, ticket updates, and remediation calls that are hard to reconstruct later. That is especially dangerous for privileged roles, administrative permissions, dormant access, and permissions assigned to AI agents themselves. These items should not be processed as ordinary low-risk review rows just because the agent can classify them.\n\nThe operator implication is simple: the agent may rank, group, draft, and route, but it should not become the approver of record. Reviewers need reasons, evidence, and policy context in the queue. Security teams need a decision record that shows the reviewer, the recommendation, the evidence used, the policy version, the time of action, and remediation status.\n\n## Control Design and Governance\n\nThe independent hardening layer comes from government guidance and agent-tool governance research. The Five Eyes guidance on careful adoption of agentic AI services recommends never granting agents broad or unrestricted access, especially to sensitive data or critical systems. It also calls for centralized policy decision points for each autonomous action, comprehensive logging of identity changes, privilege changes, tool calls, memory interactions, decisions, and actions, plus versioning and rollback to return to known-good behavior.\n\nFor recertification, this means RBAC and policy enforcement must sit in the runtime path, not in a design document. The agent should request scoped access for a specific review task, receive only the data and tool permissions needed, and pass proposed writes through policy checks before execution. A keep or revoke draft is not the same as a completed access change. The system should preserve that distinction in the workflow, audit trail, and user interface.\n\nHuman approval gates need to be designed by operators, not delegated to the agent. The Five Eyes guidance specifically says human approval should be required for high-impact or hard-to-reverse actions, and that approval decisions must be set by designers and operators. In access reviews, that points to blocking HITL gates for privileged access, admin-role access, anomalous assignments, dormant sensitive access, and any remediation that would be difficult to reverse cleanly.\n\nA useful technical pattern appears in the OpenPort Protocol, which describes scoped policy enforcement, draft-first writes, human review, idempotency, state revalidation, fail-closed behavior, and structured audit events. Its State Witness concept is particularly relevant: before executing a write, the system revalidates that the execution-time state still matches the approved preconditions. If the access state changed after approval, the workflow should fail closed rather than apply a stale revocation or approval.\n\n## Rollout Plan for Operators\n\nGate one is shadow mode. The agent ingests entitlement data, last-access signals, assignment context, role or peer context, policy version, and reviewer ownership data where available, then generates keep, revoke, or needs-review drafts without showing them as default decisions. A sampled review of recommendations should compare agent reasoning with human outcomes, policy exceptions, and remediation results. The goal is to learn where the agent is reliable enough to help routing, not to prove it can replace reviewers.\n\nGate two is advisory mode with mandatory human decision. Recommendations can appear in reviewer queues, but every item still requires a human keep or revoke decision. Low-risk items may be batched to reduce context switching. Higher-risk items should be separated into blocking queues with stronger evidence requirements, owner visibility, and explicit approval capture.\n\nGate three is policy-bounded automation for reversible low-risk actions. This is where the vendor-reported speed compression may become relevant, but only for narrow queues whose failure modes are understood. Operators should require runtime policy checks, scoped credentials, structured audit events, monitoring of tool calls, and remediation paths that can be reversed without manual archaeology. Auto-apply settings should be treated as a control decision, not a convenience toggle.\n\nGate four is auto-remediation only after operational proof. The system should pass state-witness checks, negative security tests, rollback exercises, and audit-artifact reviews before it changes access without a case-by-case human click. Continuous evaluation should determine whether autonomy expands, stays fixed, or rolls back. If completion-rate reporting improves but evidence quality declines, the rollout has optimized the wrong metric.\n\nAccess-recertification agents are best staged as control amplifiers, not decision substitutes. Let them assemble evidence, expose outliers, route work, and draft recommendations, while humans retain approval authority for material access changes. Automation can be introduced for reversible low-risk queues only after runtime policy enforcement, monitoring, evidence capture, and rollback are working. Stage the next release around approval gates, not around agent confidence alone.",
  "title": "How to Stage Access-Recertification Agents Without Turning Reviews Into Rubber Stamps",
  "updatedAt": "2026-05-30T13:57:52.411Z"
}