TL;DR: Oak says an identity security proof of concept should run on the hardest application in your estate, not a vendor sandbox, and should prove a full chain from entitlements and identity discovery through ownership, certification and revocation at the source. The test only matters if it validates real governance on live data, because dashboards without verified remediation leave the underlying access risk untouched.
At a glance
What this is: Oak frames identity security PoCs as end-to-end governance tests, with verified revocation at the source as the key pass or fail criterion.
Why it matters: For IAM, IGA, PAM and NHI teams, this matters because PoCs that stop at visibility or tickets do not prove control over live access paths.
👉 Read Oak's guide to identity security proof of concept requirements
Context
A useful identity security proof of concept does not begin with dashboards, it begins with the governance gap between what a platform can see and what it can actually change. In practice, many evaluations stay inside clean sample data and never touch the tangled entitlements, ownership gaps and dormant access that define real identity risk.
The point of the PoC is to prove whether the platform can govern your hardest application, resolve accountable ownership, and write revocation back at the source. That makes the evaluation a test of identity control, not a demo of connector coverage.
For teams evaluating IGA buyer's guide criteria, this is the difference between proving reporting and proving remediation on the systems that matter most.
Key questions
Q: What should an identity security PoC prove before you trust the results?
A: It should prove that the platform can govern a real, difficult application end to end. That means ingesting entitlements, finding non-human identities, resolving accountable owners, running certification with your reviewers, and writing revocation back to the source with confirmation. If any step stays in a ticket or a demo dataset, the evaluation has not proved operational control.
Q: Why do sandbox evaluations miss the governance gaps that matter?
A: Sandbox evaluations miss the hidden structure of real systems. Clean data, prebuilt roles and simplified connectors hide nested entitlements, inherited access and stale grants, which are exactly the conditions that make identity governance hard. A credible PoC has to confront those conditions in the live application, or it only measures the vendor environment.
Q: What should teams do when a PoC cannot revoke access at the source?
A: Treat that as a failed control test, not a partial win. If revocation stops at a workflow ticket or external approval step, the access still exists in the application and the exposure window remains open. The evaluation should only pass when the source system reflects the removal and the platform can verify it.
Q: How should organisations compare identity security vendors in a PoC?
A: Compare them on the same end-to-end chain, not on presentation quality. The best test is whether each platform can connect to your hardest application, classify every relevant identity, prove accountable ownership, complete certification with your reviewers and confirm revocation in the source system. That tells you how much of your estate the product can actually govern.
Technical breakdown
Why sandbox data hides the real entitlement problem
A sandbox PoC is usually pre-modeled, which means the data, roles and connectors were already shaped to be easy. That hides the real problem: nested groups, inherited admin rights, stale grants and out-of-band entitlements that exist only inside the application. A serious PoC has to ingest fine-grained entitlements, not just role names, so the platform can reconstruct what access actually exists after inheritance and usage are resolved. It also has to prove it can connect to systems your current governance stack never reached. The real question is whether the platform can see the live identity model, not a curated replica of it. Practical implication: test the platform against the least convenient application you own, not the most polished one.
Practical implication: test the platform against the least convenient application you own, not the most polished one.
How ownership and certification should work in a real PoC
A PoC should not treat ownership as a default field or a manual cleanup task. Every service account, contractor, bot and AI agent in scope needs an accountable human owner, with evidence for why that owner was chosen. Certification should then run with your own reviewers, using your own data, so the test proves that access decisions are made by the people who actually manage the risk. This is where many evaluations fail: the vendor staff drive the workflow, or the reviewers are given a simplified list that omits the messy parts of real governance. Practical implication: require named owners and real reviewers before you accept any certification result. See the IGA Buyer's Guide.
Practical implication: require named owners and real reviewers before you accept any certification result.
Why revocation at the source is the decisive control
Revocation is the only PoC outcome that proves governance changed the system of record. If a certification decision ends in a ticket, the access still exists until some other team closes the loop. A valid PoC therefore has to push the removal into the target application and then re-read the application to confirm the access is gone. That turns remediation from an administrative handoff into an enforced control. For identity security, verified revocation matters more than a dashboard because it shortens the exposure window, especially where dormant entitlements and unmanaged credentials have been living for months. Practical implication: score the platform on confirmed source-side removal, not on closure status in a separate workflow. See the Secrets Management Buyer's Guide.
Practical implication: score the platform on confirmed source-side removal, not on closure status in a separate workflow.
Threat narrative
Attacker objective: The attacker aims to turn unmanaged identity access into durable control over the target application and the data or systems it protects.
- Entry begins when an attacker lands on real credentials or stale access inside a live application, not a sandboxed environment.
- Escalation follows when inherited rights, hidden entitlements or unmanaged service accounts expose broader access than the organisation expected.
- Impact occurs when the attacker reaches the same permissions the PoC should have been able to govern, showing that visibility without verified revocation leaves exploitable access in place.
Breaches seen in the wild
- Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Verified revocation, not visibility, is the control that separates a real PoC from a sales demo. If the platform cannot write change back into the source application and confirm the result, it has only observed risk. That means the evaluation has not tested whether identity governance can shorten exposure in the system that actually matters. Practitioners should treat source-side revocation as the pass condition, because everything else is supporting evidence.
Hardest-application testing is a governance requirement, not a technical preference. The moment a PoC avoids the least integrated system, it stops measuring the platform against real identity sprawl. This is where hidden entitlements, out-of-band access and inconsistent ownership usually live, so the test must begin there to be credible. The implication is that selection criteria should reward coverage depth before interface polish.
Identity governance breaks when ownership is inferred rather than proven. A service account, bot or AI agent without an accountable owner is not certifiable in any meaningful sense. The issue is not just inventory, it is governance legitimacy: if nobody can own the decision, nobody can retire or defend the access. Practitioners should require evidence-based ownership resolution as part of the evaluation.
Why NHI security matters now is visible in the PoC design itself. The article’s test model assumes that machine identities, AI agents and human reviewers all coexist in the same operational graph. That is the right frame for modern identity programmes, because the same governance chain now has to handle human approvals, non-human access and remediation proof in one loop. Practitioners should evaluate platforms on how well they preserve that chain without forcing a separate process for each identity type.
From our research library:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: NHI Security Platform Buyer's Guide
What this signals
Source-side remediation is becoming the real benchmark for identity governance maturity. Many programmes can report on access, but far fewer can prove that a reviewer decision becomes an enforced change in the target system. When that loop is missing, the organisation still depends on manual follow-through, and the control boundary is weaker than the dashboard suggests.
The practical signal for teams is that evaluation criteria should shift from connector breadth to closure quality. If your PoC cannot demonstrate verified revocation in the same application that holds the access, then the platform is still measuring identity risk rather than governing it.
The same logic applies across human and non-human identity programmes: the governance value sits in the ability to change source state, not merely document it. That is why PoCs now need to test ownership, entitlement depth and revocation in one chain, not as separate capabilities.
For practitioners
- Test the hardest application first Use the least convenient production application you own, especially the one your current IGA never reached, and fix the scope before the demo begins.
- Require source-side revocation proof Make at least one certification decision remove access in the target system and then re-read the system to confirm the entitlement is gone.
- Demand accountable ownership for every identity Insist that every service account, contractor, bot and AI agent in scope resolves to a named owner with evidence, not a placeholder field.
- Score remediation above dashboards Weight verified revocation and source-side change more heavily than reporting depth, because reporting without closure leaves the risky access live.
Key takeaways
- A credible identity security PoC has to test a live, difficult application, because clean sandbox data hides the entitlements and ownership gaps that create real governance risk.
- Verified revocation at the source is the clearest proof that the platform can change access, not just report on it.
- PoCs that stop at dashboards, tickets or simplified datasets do not prove control over human, non-human or AI agent identities.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Key Challenges and Risks · NHI Security Platform Buyer's Guide · IGA Buyer's Guide · Secrets Management Buyer's Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centers on proving revocation and offboarding at the source, which is the core NHI-01 issue. |
| NHI-05 — Overprivileged NHI | The PoC requires discovery of hidden and inherited access, a direct overprivilege problem in live applications. | |
| NHI-10 — Human Use of NHI | The need for accountable owners and human reviewers maps to the governance boundary around human control of non-human access. | |
| Recommendation — Test whether the platform can revoke and retire non-human access in the source application, not just log the request. Use the PoC to expose overprivileged service accounts, bots and AI agents that your current governance stack misses. Require evidence that every non-human identity has a human owner and a human reviewer before certification passes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing entitlements and proving access removal in the source system. |
| Recommendation — Validate that entitlements are identified, approved and revoked with source-level confirmation in the PoC. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The source article cites credential abuse and the PoC is aimed at exposing the access paths attackers exploit. |
| Recommendation — Map uncovered access paths to credential access and lateral movement risks, then prioritise the systems with the widest blast radius. | ||
Key terms
- Identity Security Proof of Concept: A controlled evaluation that tests whether an identity security platform can govern real access in a live environment. In practice, it should prove coverage, ownership, certification and source-side remediation on the systems that matter, not just display findings in a dashboard.
- Source-side revocation: The removal of access directly in the target system where the entitlement exists. This matters because tickets and external workflows do not reduce exposure until the source application reflects the change, which is why verified revocation is the strongest evidence of control.
- Out-of-band entitlement: Access that is granted inside an application outside the normal request and approval process. These entitlements are often invisible to legacy governance tools, which is why PoCs need to test for them on real systems rather than assume they are already modeled.
- Accountable Owner: An accountable owner is the person or team that knows what business service, application, or process would break if a machine identity disappeared. This role is different from the governing function. The accountable owner provides operational context, objections, and approval boundaries when revocation or right-sizing is being considered.
What's in the full article
Oak's full article covers the operational detail this post intentionally leaves for the source:
- The exact PoC acceptance chain from entitlements through verified revocation in the target application
- The red flags that should fail a vendor if the demo shifts to a sandbox or narrowed scope
- The weighted scoring rubric for remediation, coverage, ownership and certification quality
- The attendee mix Oak recommends for evaluating the platform with real governance stakeholders
👉 Oak's full post covers the scoring rubric, red flags and PoC attendee roles in more detail.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org