Introduction

An identity security proof of concept (PoC) should run on your hardest application, the one your current tools never reached. Require the platform to ingest its fine-grained entitlements, discover its service accounts and AI agents, and resolve an accountable owner for each.

Then require a real certification with your own reviewers, and a revocation written back at the source with proof it held. Anything less tests the vendor's demo instead of your estate.

Oak, the AI-native identity operating system, lands beside the identity governance and administration (IGA) platform you already run and starts with the part it has never seen.

This guide covers the test target, the requirements, the pass or fail criteria, who should attend, the red flags, and how to score the results.

Key takeaways

• Test on your hardest application, never on a vendor sandbox.
• Require one chain: entitlements, discovery, ownership, certification, verified revocation.
• Weight remediation with proof above dashboards when you score vendors.
• Hold Oak to the same identity security proof of concept requirements as any vendor.

Why a sandbox proof of concept proves little

A vendor sandbox is a pre-modeled environment where the data, roles and connectors were shaped before you arrived. Its entitlements are clean by design, so they cannot show you the nested groups, inherited admin rights and stale grants in your own applications.

Real risk sits in real credentials. Verizon's 2026 Data Breach Investigations Report found credential abuse somewhere in the attack chain of 39% of breaches.

A PoC earns its cost only when it runs on your credentials, your entitlements and your reviewers. Oak's Identity Risk Visibility & Intelligence reasons over that live data, which is the kind of evidence a sandbox cannot produce.

Choose your hardest application as the test target

Your hardest application is the on-prem, homegrown or custom system your IGA never reached. Pick it, because a platform that can govern it is unlikely to struggle with your well-connected SaaS apps.

That system usually holds out-of-band entitlements. An out-of-band entitlement is access granted directly inside the application, outside any request or approval workflow, so it never reaches your identity model.

Ask each vendor how it will connect, and get the method in writing:

• A pre-built connector for the application
• A custom connector built for the application
• A file upload of the application's entitlement export
• A direct API or database connection
• An on-prem agent for systems behind your firewall

Oak connects through each of those methods, and its ConnectAny reaches the on-prem, homegrown and custom systems that legacy connectors leave waiting.

What to require end to end

Treat the requirements as one chain that runs from raw data to a verified fix. If any link breaks on the target system, the platform fails the test.

Ingest fine-grained entitlements

Require resource-level permissions, mapped to privilege level (admin, write, read) and to the sensitivity of each resource. Role names alone hide what a role actually grants.

Require usage alongside assignment. Effective access is what an identity can actually reach once nested groups and inherited rights resolve, and usage shows whether it exercises that reach.

Discover service accounts and other non-human identities

The 2026 Identity Security Landscape survey counted 109 machine identities for every human. Most of them will never appear in a manager-led review.

Require the platform to find the machine identities and AI agents in the target system that your IGA cannot tie to a person, and to classify each one by type.

Resolve an accountable owner

Every identity needs certifying: service accounts, contractors, RPA bots, and AI agents, each tied to an accountable human owner. Without an owner, nobody can approve, review or retire that identity.

Require the platform to resolve each owner from evidence, such as who created the identity, and to show its reasoning.

Run a real certification with real reviewers

Run a certification inside the test, with your own reviewers and your own data. Require last-used dates, resource sensitivity and a recommendation on every row, and proof that no reviewer certified their own access.

Oak continuously correlates what every identity can access with what it actually uses, then routes risk-prioritized decisions to the right reviewers.

Revoke at the source, with proof

Require at least one revocation from the certification to be written into the target application. Then require the platform to re-read the application and show the access is gone.

Revoke-driven deprovisioning means a reviewer's decision triggers the removal directly. A ticket handed to another team does not count, because the access stays live until someone closes it.

Pass or fail criteria for an identity security proof of concept

Agree on these criteria with every vendor before the test starts, so each faces the same bar.

RequirementPassFailTarget system connectedLive connection to your named application by an agreed methodSandbox data or a different applicationFine-grained entitlementsResource-level permissions with privilege level, sensitivity and usageRole names or group lists onlyMachine identity and AI agent discoveryFound and classified inside your applicationShown only from a prepared datasetAccountable ownerNamed person or team for each identity, with reasoningBlank owner field or a generic placeholderCertificationYour reviewers decide with context, and no reviewer certifies their own accessVendor staff click through decisionsRevocationWritten at the source and confirmed by a re-readTicket opened, change never verified

Mark a requirement as failed if the vendor has to change your scope to pass it. Oak closes the loop on the last row, remediating from the source the moment an identity deviates.

Who should attend

Staff the test with the people who will run the platform after purchase. Each one checks a different link in the chain.

• The IAM architect, who owns the connection method and the identity model
• The owner of the target application, who confirms entitlements and sensitivity
• Real reviewers, who certify access they actually manage
• Your governance, risk and compliance lead, who checks the evidence an auditor would accept
• Security leadership, who signs the go or no-go decision

Ask each vendor to name its attendees and whether they will also implement the platform. Oak offers a free white-glove implementation program for qualifying large enterprises.

Red flags in a proof of concept

Rescore the vendor, or walk away, when you see any of these:

• The test runs only in a vendor sandbox
• Entitlements arrive as a spreadsheet of role names
• Machine identities and AI agents appear as a separate list with no owners
• Vendor staff run the certification in place of your reviewers
• Remediation ends in a ticket nobody verifies
• The scope quietly narrows to applications the vendor already supports

Oak keeps human, machine and AI agent identities on one live graph as part of its AI agent identity governance. Each agent runs continuous reviews driven by its own risk profile, not a fixed calendar, with access checked against actual usage and excessive permissions removed at the source.

How to score results against a weighted rubric

Score each criterion as fail, partial or pass, worth 0, 1 or 2 points. Multiply by the criterion's weight, then compare totals across vendors.

CriterionWeight (1 to 5 points)What earns full marksRemediation with proof5Revocation written at the source and confirmed by a re-readCoverage of the target system5Live connection, fine-grained entitlements and usageMachine identity and AI agent discovery and ownership4Every identity classified with an accountable ownerCertification quality4Real reviewers, context on every row, no reviewer certifies their own accessFit beside your IGA3Connects to your IGA and covers what it cannot reach

Remediation carries the top weight because verified revocation shortens the window an attacker has. IBM's Cost of a Data Breach Report 2026 put the global average breach at a record $4.99 million, up 12% on the prior year.

Already running an IGA? Score fit on whether a platform builds on it. Oak connects to the IGA you already run and covers what it cannot reach, so working governance stays in place.

Conclusion

For a CISO, a strong identity security proof of concept ends in a go or no-go decision that a board and an auditor can follow. For an IAM lead, it ends in proof that the platform will govern the systems your IGA never reached.

Oak gives you that evidence from one live graph, beside the IGA you already run.

Bring your hardest application and this rubric, and book a demo with Oak to see how it measures up.

Frequently asked questions

How many applications should an identity security proof of concept include?

An identity security proof of concept should include your hardest application and one familiar application as a control. The control shows whether the platform's findings match what your IGA already reports, which tells you how far to trust the rest. Name both applications to Oak before the test so the scope is fixed.

What is the difference between an identity security PoC and a pilot?

An identity security PoC tests whether a platform can govern your hardest application, while a pilot tests whether your teams can run it in production. Run the PoC first, because a pilot on an easy application hides the coverage gaps that matter. Ask Oak which stage your evaluation fits before you commit people to it.

How long should an identity security proof of concept run?

An identity security proof of concept should run long enough to complete one full chain on the target system, from ingestion to a verified revocation. Fix that end point in writing rather than a calendar date, so no vendor can declare success early. Agree the same end point with Oak and every other vendor.

How should you involve the incumbent IGA in an identity security PoC?

Involve the incumbent IGA in an identity security PoC as the baseline, comparing the identities it knows with everything the candidate platform finds. The difference is your dark footprint, and it should be measured rather than estimated. Oak reads the incumbent's policies and roles, so that comparison runs without rebuilding them.

What should you bring to an identity security PoC kickoff?

For an identity security PoC kickoff, bring the target application's name, its connection constraints, a redacted entitlement export and the reviewers who will certify. Agree the pass or fail table before anyone connects, so results are judged against criteria set in advance. Oak works from the same inputs on a demo call.

‍