AI Identity Governance Assessment
Most AI deployments create identities that no lifecycle process governs. We surface them, then test whether your organization can prove three things about each one: who owns it, what it exists for, and what data it can reach — down to the entitlement.
What Is AI Identity Governance?
AI identity governance is the practice of accounting for every identity, human and non-human, through which an AI system can reach your data — and for the entitlements each of those identities holds. The question is not what a model was trained on, which nobody can reconstruct from the outside. It is which of your systems AI can touch, through which accounts, and to what depth. In practice that is AI agent identity management: the service principals, integration accounts, API keys and connector identities that let your models reach data and call external systems. They are created outside your joiner-mover-leaver process, they are rarely owned, and they are almost never certified. This assessment addresses that infrastructure and integration layer — service principals, application registrations, API keys, and pipeline and connector accounts.
Most AI governance work maps controls to a framework and produces a binder. This assessment does the opposite. Rather than asking whether an AI policy exists, it measures whether that policy is true, by correlating every account in the systems you export against your authoritative identity sources. The correlation and classification method behind it is not new: GCA has run it in production identity programs at enterprise scale, across thousands of accounts and multiple applications, before ever pointing it at an AI estate.
One distinction runs through the whole engagement: GCA does not assign owners to your accounts. We merge your authoritative identity sources — HR, a provider registry, a contractor system — into a single identity spine, establish which accounts sit outside it, then measure how well your organization can account for them: who owns each one, what it exists for, and whether its existence can be defended. The deliverable is a readout on how well your program answers those questions, not an inventory we filled in on your behalf.
Why a Policy Is Not an Attestation
No regulator has yet issued an AI-specific identity governance mandate. But HIPAA, SOX and the SEC cybersecurity disclosure rules already require that systems handling regulated data have auditable access control, and AI systems are not exempt from rules that already apply.
The gap shows up the moment an auditor asks something specific:
- Healthcare — which service accounts read the EHR on behalf of a clinical decision-support model, and who approved each one?
- Financial services — which identities provision the data feeding a risk or fraud model, and are any of them attached to someone who has left?
- Energy and utilities — which accounts hold broad read access to operational data for forecasting and fault detection?
- Public companies — can you produce, on demand and with evidence, a list of every account an AI system reaches your data through, and what each one is entitled to?
In most environments the answer is either a list assembled by hand from six systems with six different identity models, or no list at all. AI access governance starts by replacing that with evidence.
How the Assessment Works
One method, applied consistently. Merge your authoritative identity sources into a single identity spine, correlate every account in every exported system against it, and treat the accounts that do not correlate as the ungoverned population. AI service account discovery is a filter applied to that population, not a separate exercise.
Scoping and Client-Run Exports
You run the extracts; GCA supplies the specification. No new privileged account is provisioned and no GCA credential enters your environment. The request is strictly control plane, never data plane: grants, roles and entitlements, never a record set or a sample of your data.
- AI system intake, environment inventory and regulated data class declaration
- Export specifications for Active Directory, Microsoft Entra (app registrations, OAuth permission grants and admin-consent records), Oracle, Snowflake, Databricks, Epic, Cerner, RACF and interface engines
- Any ownership context you already hold, including correlation results and owner assignments from an existing IGA platform — both an input to the work and a measure of how far your program already gets on its own
Identity Spine and Correlation
Authoritative sources merge first, resolving people who appear in more than one: the clinician in both HR and the provider registry, the contractor in both HR and your vendor system. Correlation then runs as a confidence-tiered, multi-key pass.
- Keys are chosen per source system — employee ID, email and normalized name are common candidates — and the hit rate of each is reported separately
- That separation distinguishes weak identity data from a wrongly chosen matching key
- The correlation rate per source system is the assessment's central number
What Every Account Tells You
Every account in scope lands in exactly one of five categories, and each carries a different remediation path.
- Correlated to an active identity — governed, and your baseline
- Correlated to a terminated identity — a deprovisioning failure, and the highest-severity finding
- Uncorrelated service or non-human account — the AI agent identity population. These need lifecycle attestation rather than a person: a named accountable owner, a review cadence, and a deprovisioning trigger. Assigning that owner is harder than it sounds, because the creator, the application owner and the business owner are rarely the same party. This is what belongs in your non-human identity certification cycle.
- Uncorrelated and unattributable — ungoverned identity discovery, and usually the headline
- Shared or generic — a governance exception requiring an explicit charter
Correlation is only half the readout. For accounts on a path to an AI system, the assessment also reports entitlement breadth. An app registration holding tenant-wide directory read is a different exposure from one scoped to a single mailbox, even when both are correctly owned.
What You Receive
Four deliverables, scoped by the number of authoritative identity sources and source systems in play. One source system means one distinct account store requiring its own export and its own correlation key.
- Orphan and Stale Credential Report — the evidence, with a Coverage and Method Statement recording what was collected, from where, and when
- Governance Gap Analysis — where your existing process fails to capture these accounts
- Remediation Roadmap — sequenced and mapped to the platform you already own
- Executive Brief — two to three pages for a sponsor or audit committee
- Tiers are set by those two counts. Focused — one authoritative source and three to five systems, about three weeks. Standard — two sources and six to ten systems, four to five weeks. Enterprise — three or more sources and eleven to twenty systems, six to eight weeks.
Frequently Asked Questions
How do you integrate IGA with AI security?
This assessment is the inventory step that identity governance depends on. It produces the account population your existing platform needs in order to certify, review and deprovision: an AI service account inventory that did not previously exist. GCA is deliberately vendor-neutral at the assessment stage, because the correlation pipeline is GCA-owned. No third-party processor sees your data, and the remediation roadmap can recommend the platform you already own. If you then choose to implement, we work across SailPoint, Okta, CyberArk, Ping, Microsoft Entra, Netwrix and ConductorOne (C1).
What data does GCA actually receive?
Access-control metadata only: accounts, roles, grants and entitlements. Never a record set, never a data sample. An Epic user and security-class export contains workforce identities, not patient records. A RACF unload contains userids and profiles, not the data they protect. Control plane, never data plane. Retention and destruction terms are agreed in writing before any export moves, and because the correlation pipeline is GCA-owned there is no third-party processor to add to your Business Associate Agreement.
What is deliberately not in scope?
Several things, stated up front so you can self-qualify. Microsoft 365 Copilot and SharePoint over-sharing is an effective-permissions problem rather than an identity-inventory one, and needs different tooling. Model risk, meaning bias, fairness, explainability and model documentation, is machine-learning governance rather than identity. ISO/IEC 42001 certification readiness assesses an entire AI management system, while this assessment measures identity facts. Ephemeral runtime tokens and dynamic session contexts sit outside this static entitlement pass, which reads persistent account and entitlement stores rather than live execution state. And discovering unsanctioned AI tools requires endpoint telemetry and software spend analysis, a different methodology entirely. We assume the AI systems and integration points in scope are identified before export begins; discovering unknown ones is a separate exercise.
What are the limits of what this can prove?
Two limits matter, and every report states both explicitly rather than leaving them to be discovered. First, static entitlements do not fully express effective access — in healthcare especially, break-the-glass workflows and treatment-relationship logic mean a clinician can reach records outside their standing role assignment. Second, and specific to AI: an account that correlates cleanly can still hold a wider effective envelope than its grant suggests. A service principal holding delegated permissions acts with the reach of whichever user consented, and a shared gateway account can proxy many downstream tasks under a single identity. We report the grant and, where the export exposes it, the delegation type, and we state plainly where the boundary sits. Where full effective-access accounting is required, audit-log analysis can be scoped separately. An identity correlation assessment tells you who is accounted for; it does not replace monitoring of what they actually did.
Where This Fits
The AI Identity Governance Assessment is one of GCA's assessment engagements. It shares its method with our wider governance work and feeds directly into implementation.
Can You Account for What Your AI Can Reach?
An AI Identity Governance Assessment runs three to eight weeks depending on scope, and produces four defensible deliverables. If you are deploying AI against regulated data, these accounts already exist. The only question is whether your organization can say who owns them and what data they can reach.