Nobody Owns the Identity Your Retention Platform Runs As

Who owns the identity the platform runs as?

The data it accesses has an owner, usually the registrar, anchored in the institutional data governance policy. The contract has an owner in procurement or the provost's office. The vendor relationship belongs to whoever manages the EdTech portfolio. The identity the platform authenticates as — the OAuth token it uses to pull SIS records, the service account it uses to write flags back to the LMS — that one doesn't have an owner.

At Westbrook University, a regional comprehensive institution of roughly 9,000 students, the answer has been nobody for approximately three years.

How the Gap Opens

Westbrook deployed Pathways AI, a predictive retention analytics platform, in fall 2022. Implementation was handled by the vendor's professional services team working alongside Westbrook's IT director and the director of student success. The platform was integrated with the Banner SIS and Canvas LMS via OAuth 2.0 service accounts and a set of API keys provisioned during the setup engagement. The IT director who oversaw the integration left for a position at a larger institution in spring 2023. The director of student success who championed the platform was promoted to associate provost in fall 2024. The current IT director inherited a working system with no documentation of how the service accounts were provisioned, what scopes they carry, or when they were last reviewed.

The platform still works. Advisors use it. The retention data looks good. The OAuth tokens are still valid. The service accounts have not been audited since implementation.

This is the default outcome when machine identity lifecycle is treated as an implementation task rather than an ongoing governance responsibility. It is common enough that it barely registers as a gap until something breaks.

The Ownership Map Has a Hole

The vendor relationship has an owner. The contract has an owner — it renews annually, and procurement reviews the terms. The student data the platform accesses has an owner, at least on paper, in the institutional data governance policy. The platform's outputs have owners in the student success office.

The machine identity the platform operates under has none. No one is responsible for rotating the OAuth tokens. No one is reviewing whether the service account scopes still match the platform's current use case — which may have expanded since implementation as the vendor added features and the institution adopted them. No one is tracking whether the credentials would survive a vendor security incident, a contract non-renewal, or a scope dispute.

This is the governance gap. Westbrook has an IdP. It has a data governance policy. It has a vendor management process. None of those processes has a defined handoff point for machine identity lifecycle. The credential falls outside all of them.

The Implementation Review Does Not Close This

The most common institutional response is some version of: "We reviewed this during implementation." That response is accurate as far as it goes.

Implementation review evaluates whether the integration was configured correctly at the moment of deployment. It says nothing about whether the service account scopes are still appropriate eighteen months later when the vendor added a new advising module, whether the OAuth tokens survived the IT director's departure intact and unreviewed, or whether the credential would be revoked if the contract were not renewed.

Machine identity lifecycle is an ongoing governance responsibility with a cadence — rotation schedules, scope reviews, offboarding triggers, contract-linked revocation procedures. Implementation review addresses none of that. Pointing to it as evidence of governance conflates a one-time configuration check with a continuous operational practice.

The AI Governance Angle Is the Entry Point

Westbrook's provost is not thinking about OAuth tokens. She is thinking about whether the institution's use of AI in student advising is responsible, auditable, and defensible to accreditors and to students who ask how their data is being used. Those are legitimate concerns, and they are live on her calendar in a way that service account hygiene is not.

The connection is direct: the platform's AI outputs are only as trustworthy as the data pipeline feeding them, and the data pipeline's integrity depends in part on whether the credentials governing its access have been reviewed, scoped appropriately, and are subject to revocation. An AI governance conversation that does not include machine identity lifecycle is incomplete. That is the structural reality of how the platform works.

This is where the Tier 2 AI governance argument has traction. The institution has deployed AI. Someone is accountable for it. The accountability framework has a gap, and it has a name.

Discovery Questions Before the Call

Before any Tier 2 engagement where an AI-enabled retention or analytics platform is in scope, pull these questions:

Ask the IT director or CISO: "When your retention analytics platform authenticates to your SIS and LMS, what credentials does it use, and when were those credentials last reviewed?" If the answer requires checking with someone else, the gap is confirmed.

Ask the VP for Student Affairs or the retention platform owner: "If you decided not to renew your contract with the retention platform vendor, what would happen to the service accounts and OAuth tokens the platform currently holds?" Uncertainty here is the opening.

Ask the provost or chief academic officer, if you get the meeting: "Your AI governance framework — does it include the machine identities your AI platforms operate under, or does it focus on the outputs and the data?" Most frameworks focus on outputs. The gap is the credential layer.

Listen for the phrase "we reviewed this at implementation." That phrase confirms the lifecycle governance conversation has not happened yet.