Permission Reviews Are Becoming Continuous Controls

Most access governance programs were designed around a simple assumption: the population being reviewed is people, and people sit on a relatively stable org chart. A new hire gets provisioned, a role change gets re-provisioned, an exit gets deprovisioned, and everything in between gets checked once or twice a year against a manager who presumably still knows what that person does. Vendors, consultants, managed-service providers, SaaS integrations, and now AI agents break that assumption in almost every direction — their relationships start and end faster than an annual cycle can track, the access they hold spans systems no single manager owns end to end, and the system that knows whether the relationship is still active is rarely the same system that knows whether the access still exists.

That gap is why a question that sounds almost too simple to need asking has become one of the harder ones in enterprise risk: the vendor may still be approved, but should it still have access? A growing body of identity-governance guidance, zero-trust architecture, and regulatory expectation is converging on the same answer — that permission review cannot stay a point-in-time certification exercise and needs to become a continuous, evidence-backed control, extended explicitly to the third-party, contractor, and machine-identity population that most legacy review programs were never built to cover.

The Access That Outlives the Reason It Was Granted

Vendor access is almost always granted for a specific, time-bound purpose: a data migration, a support engagement, an API integration, a one-off diagnostic session, a pilot that was supposed to run ninety days. What rarely happens with the same discipline is time-boxing the access itself to that purpose. A support engineer's temporary portal login survives the ticket that created it. A consultant's read access to a shared drive survives the engagement. An integration's API key survives the vendor swap that made it redundant. None of this is negligence in the usual sense — it is what happens by default when access provisioning has a clear trigger and access de-provisioning does not.

The certification process meant to catch this drift has its own, well-documented failure mode. Identity-governance practitioners have flagged for years that periodic access certification — a manager or system owner working through a list of entitlements on a fixed schedule — degrades under volume. Faced with dozens or hundreds of undifferentiated line items in a single sitting, a reviewer has little practical basis for genuine per-line judgment, and the pattern that results has picked up a name in the field: rubber-stamp certification, where approval rates run extremely high and revocation rates stay close to zero almost regardless of whether the underlying access is still needed. A review that never revokes anything is not evidence that everything reviewed was justified — it is usually evidence that the review stopped functioning as a control.

Why the Annual Review Can't Keep Up With Vendor Access

Baseline access-control guidance has long required periodic review as a minimum standard. NIST's Special Publication 800-53 sets out account management and access-enforcement controls built around need-to-know — access authorized on the basis of an individual's, or in this case a vendor's, current and specific authorization, not a historical one. The control was written with an implicit assumption that "periodic" is frequent enough relative to how fast the underlying population changes. For a reasonably stable employee headcount, that assumption mostly holds. For a vendor and contractor population that turns over through contract renewals, sub-contracting, project completions, and platform migrations on a rolling and largely unsynchronized basis, a fixed annual or semi-annual date is frequently already stale by the time the review runs.

Zero-trust architecture has been explicit that the fix is a shift in cadence, not just a tightening of the same periodic model. CISA's Zero Trust Maturity Model frames the identity pillar's advanced and optimal stages around continuous validation rather than a static, point-in-time authorization decision, and consulting guidance has converged on the same principle from the private-sector side. Deloitte's own perspective on the identity dimension of zero trust puts it plainly: the model requires that "every user, device and traffic flow is known, authenticated, authorised and monitored — at all times," with access granted on the basis of dynamic, contextual authorization rather than a static rule set reviewed on a calendar. Vendor access sits squarely inside that requirement, yet is frequently the part of the estate least covered by it, because most continuous-verification and adaptive-access investment has gone toward employee and customer-facing identity first.

The deeper structural issue for third parties specifically is that the two systems that would need to talk to each other to make recertification meaningful usually don't. A vendor's lifecycle status — active, under enhanced monitoring, contract ending, formally offboarded — lives in a TPRM or procurement system, owned by risk, compliance, or procurement teams. The vendor's actual technical footprint — logins, API keys, service accounts, integration credentials — lives in IAM and infrastructure systems, owned by IT and security. A vendor can be downgraded, flagged, or fully exited on the risk side while its credentials remain untouched on the access side, because no automated signal tells the access layer that the relationship layer has changed. Every high-profile case of an offboarded or terminated third party retaining live access traces back to exactly this gap, not to a single reviewer's mistake.

The Eight-Link Vendor Access Recertification Chain

Closing that gap does not require rebuilding either system — it requires an explicit chain connecting a vendor's identity to every access decision made in its name, so that a change at either end of the chain is visible at the other. Eight links carry that chain from a vendor's current status through to a defensible revocation decision.

Every link in this chain already exists in some form in most enterprises — vendor status somewhere in TPRM, entitlements somewhere in IAM, owners somewhere in a spreadsheet, expiries rarely anywhere at all. What is usually missing is the connective tissue: a mechanism that walks the chain automatically whenever any one link changes, rather than requiring someone to remember to check the other seven links every time one of them moves.

Building an Access Governance Program That Actually Covers Third Parties

Most enterprises already run some form of access certification. Far fewer have extended it deliberately to the third-party population, and fewer still have built the cross-system correlation that would make a vendor's recertification cycle mean anything beyond a checklist being completed on schedule. Seven practices distinguish programs that have made that extension from the ones still treating vendor access as a footnote to the employee review.

The fourth and sixth practices tend to separate programs that are actually closing this gap from ones still documenting intent. Automatic correlation matters because the highest-severity finding in this category — live access tied to a relationship that has formally ended — is entirely preventable the moment the two systems of record are made to talk to each other, yet remains one of the most common findings auditors report precisely because that correlation is still done manually, if at all. And scoring revocation rates rather than completion rates matters because it is the only reliable signal that distinguishes a genuine review from a rubber-stamped one; a program that tracks only whether the review happened, rather than what the review found, cannot tell the difference between "nothing needed to change" and "nobody looked closely enough to notice."

Where Agentic AI Fits

The reason this correlation stays manual in most enterprises is not lack of will — it is scale. A vendor-risk or IAM team large enough to manually cross-reference every third-party lifecycle event against every entitlement record, across dozens or hundreds of connected systems, is a team most organizations simply do not staff, and could not staff cost-effectively even if they wanted to. That mismatch between the volume of correlation work required and the headcount available to do it manually is exactly the gap agentic AI is built to close.

Applied to this problem, an AI-led monitoring layer can continuously watch for the specific triggers that should set the recertification chain in motion — a vendor's TPRM status changing, a contract reaching its end date, a risk tier downgrade, a change in the vendor's ownership or key personnel — and immediately surface which access grants tied to that vendor have lost their current justification, rather than waiting for the next scheduled review to stumble across them. It can maintain the recertification chain itself across cycles: tracking which grants have an assigned owner and which don't, which have passed their expiry date without renewal, and which have gone an unusual length of time without any justification update at all. It can also assemble the evidence a reviewer needs to make a fast, informed decision — current business context, prior justification history, related access held by the same vendor — instead of handing a reviewer a bare list of entitlement codes and expecting genuine judgment in under ten seconds per line.

What agentic AI does not do, and should not be positioned as doing, is make the accept-or-revoke call on a genuinely ambiguous case without a human in the loop. Whether a vendor still active under a renegotiated contract should keep a legacy integration, whether a shared service account represents an acceptable operational reality or an unacceptable accountability gap, and whether a lapsed recertification should trigger immediate revocation or a short grace period remain judgment calls for a named risk or access owner. The AI's role is to make sure that owner is looking at the right cases, with the right evidence, on a cadence that matches how fast the underlying risk actually changes — not to remove the human decision from a chain where accountability has to remain traceable to a person.

This discipline connects directly to work most mature identity and third-party risk programs are already building toward. It extends the same logic behind continuous access governance and segregation-of-duties monitoring specifically into the vendor and AI-agent population, and it sits alongside the growing recognition that AI agent identities need the same governance discipline as human accounts. It also closes a gap that vendor offboarding programs and broader third-party access management initiatives have flagged from the other direction — that an offboarding decision made in a risk or procurement system is only as good as the access-layer action it actually triggers. All of it points to the same conclusion: a permission review that only runs once or twice a year, on a population that changes weekly, is not a control weakness at the margins. It is a structural gap in exactly the layer most enterprises assume is already covered.

Frequently Asked Questions