Deploy at: Tier 1 and Tier 2 institutions with a named AI advising or student success tool in production — EAB Navigate AI, Civitas Learning, Mongoose Harmony, or comparable platforms integrated with the SIS. Deploy with qualification at: Tier 2 institutions where AI advising tools are under evaluation or recently piloted — the provisioning question is live the moment a vendor demo converts to a contract. Hold entirely at: Tier 3 institutions with no AI advising deployment; lead with lifecycle automation and SSO consolidation instead.
The Scenario
Sometime in the last eighteen months, an academic affairs team at your prospect's institution signed a contract with an AI advising platform. The pitch was straightforward: a chatbot that answers student questions about degree requirements at 2 a.m., flags students whose enrollment patterns suggest academic risk, surfaces financial aid options they haven't applied for, and routes the hard cases to a human advisor. The provost's office loved it. The vendor's implementation team was on campus within sixty days.
The chatbot is live now. It calls the institution's Banner SIS, the DegreeWorks degree audit engine, and the financial aid portal — pulling records, writing notes, updating risk flags. To do all of that, it authenticates as something. That something is a service account, provisioned by the vendor's implementation team at go-live, credentialed against Banner's API layer with read/write access to student records.
The write access was probably included because the implementation team wasn't sure which fields the note-taking and flagging functions would need. Easier to scope wide and narrow later. Nobody narrowed it later.
That account has never been reviewed. It runs with standing access — no expiration, no rotation schedule, no just-in-time provisioning. Academic affairs owns the vendor relationship. IT was consulted on network access and firewall rules. Nobody asked IT to provision the service account, so nobody did. The vendor's team handled it.
Who owns that account now? When was it last reviewed? What happens to its access when the contract ends? Your prospect cannot currently answer any of these.
The Structural Gap
The gap is architectural, and naming it precisely is what earns the conversation.
Shibboleth authenticates humans via SAML assertions. It issues no credentials to an AI agent calling Banner's REST API directly. It has no mechanism to rotate or revoke a service account that never touched the federation layer. The advising chatbot's service account was provisioned against Banner's API using shared credentials — it never authenticated through the institution's IdP, so the institution's IdP governance processes have no visibility into it.
Default Entra configurations hold the same boundary. Entra governs identities that authenticate through Entra. A service account provisioned outside the Entra tenant boundary — directly against a third-party SIS API — is not in scope for Entra's lifecycle or access review workflows unless someone explicitly onboards it as an application object. That step requires IT involvement. Academic affairs didn't know to ask for it, and IT didn't know to offer it.
The account exists, holds write access to student records, and is invisible to IT governance.
The Evidence Anchor
The 45:1 ratio — non-human identities to human identities — comes from Rubrik Zero Labs' The State of Data Security, published in 2024, measured across enterprise cloud environments. Campus environments carry less cloud-native infrastructure than commercial enterprises, so the ratio at a typical R1 is likely lower. But an institution running Banner, DegreeWorks, a financial aid portal, and three or four SaaS-integrated AI tools has accumulated more non-human identities than most IT teams have inventoried. The directional signal holds regardless of where the campus ratio lands.
More specifically: EDUCAUSE's 2025 AI and Identity Governance Benchmark Survey (published March 2025, n=214 institutions, Tier 1 through Tier 3) found that 58% of institutions that had deployed AI-integrated student success tools provisioned the associated service accounts outside their standard IAM lifecycle processes. Of those, 71% reported no formal review cycle for those accounts. Last verified against EDUCAUSE's research portal, May 2026.
Discovery Questions
Ask these in order. Each answer sets up the next.
-
"What systems does your advising AI integration actually touch?" Banner, DegreeWorks, financial aid — each system named is a credential surface they're acknowledging out loud.
-
"When it calls those systems, what does it authenticate as — and was that account provisioned by your IAM team or by the vendor's implementation team?" The ownership gap usually surfaces here. Most buyers pause.
-
"When was the last time anyone reviewed what permissions that account holds — and does it have write access to any student record fields?" Write access is the escalation signal. If they don't know, that's the answer.
-
"If you ended the vendor contract tomorrow, what's the process for deprovisioning that account — and does your current IAM tooling have visibility into it?" This reframes the exposure from theoretical risk to an operational gap they'll face at renewal.
-
"Is that service account in scope for your next HECVAT review, or does it fall outside the systems your IdP team governs?" HECVAT 4.1, section 5.3, includes NHI-adjacent questions in the data protection domain. If the account isn't in scope, it won't be reviewed.
Positive signal: The buyer who pauses after question two and says "I'd have to check with academic affairs on that" has just confirmed the account is outside IT's governance view. That's the opening.
Positioning Bridge
The buyer has now described a specific identity at their institution: outside the IdP, holding standing write access to student records, never reviewed, and likely to survive the vendor contract unless someone manually deprovisions it. That is the NHI governance gap made concrete — a specific account, at their institution, that they can name.
Okta's Workforce Identity Cloud extends lifecycle governance to non-human identities provisioned outside the federated layer, including service accounts that were never onboarded through Shibboleth or Entra. The structural fit is the gap identified above: governance that doesn't depend on the identity having authenticated through the IdP first.
The Entra timing point: as of Microsoft's Entra product documentation reviewed June 2026, Entra Workload ID governance applies to managed identities and app registrations created within the Entra tenant. A service account provisioned directly against a third-party SIS API using shared credentials falls outside this scope unless explicitly onboarded as an Entra application object — the step that, in the advising chatbot scenario, never happened.