With CustomGPT.ai‘s End User IdP Login feature, you can select which students or faculty can chat with AI tools you have created with CustomGPT.ai. They log in using your university SSO and receive access to tools bed on attributes they have in your IdP system like which courses or associations they belong to.
TL;DR
If you want a university AI chatbot that isn’t public, use campus SSO and route students by enrollment entitlements. End User IdP Login lets students authenticate via the IdP and reach only the course agents their role allows, without student account management inside CustomGPT.- Best for: IAM-led deployments that need low ticket volume
- Decision trigger: You need course routing like biology-101 vs history-202
- Watch-out: minimize enrollment attributes, avoid rosters and schedules
What This Rollout is
This rollout pattern gives students chat-only access to specific course agents using the university’s existing identity provider. It’s meant for scale: thousands of students, minimal ticket volume, and no “public link” exposure. End User IdP Login is different from “staff SSO.” Staff SSO signs internal team members into CustomGPT. This feature signs end users into a portal experience that only exposes the agents their role allows. When we say “no student accounts,” the precise promise is: no CustomGPT end-user account is created, so there’s no manual student provisioning or account management inside CustomGPT. Students still exist in your university IdP, and that IdP is what authenticates them. Learn more about how SSO works and deploying AI agents without managing users.Why Public Links Fail
You can build a great student-facing agent and still fail rollout if access is “anyone with the link.” At university scale, link sharing is normal, devices are shared, and the audience boundary gets blurry fast. Here’s the key identity clarification: Students authenticate via the university IdP, but no CustomGPT end-user account is created, so this is not “public” or anonymous access in the usual sense. Access is still controlled by your campus identity system and the roles you define. This post focuses on the portal URL model because it’s the cleanest way to handle “one link for all students” with role-based routing, without turning your rollout into a custom app project.Course Routing Template
Course routing works best when you treat enrollment as an entitlement key, not as a roster export. The goal is to route a student to the right agent without passing a full schedule, class list, or unnecessary identifiers. A simple template is: course role name equals IdP attribute value, and each course role is assigned only to its course agent. If a student belongs to multiple courses, they see a portal picker instead of a forced redirect. You can create agent-specific custom roles for this purpose. The failure mode to plan for is over-broad entitlements. If a single attribute value unintentionally maps to multiple roles or too many agents, students will either see irrelevant options or file tickets because “the wrong bot showed up.”Example Routing
A professor (or program owner) maintains two agents: one for biology-101 and one for history-202. Your IdP sends a single attribute whose value is the course entitlement key for that student. If the student has access to one course agent, they land in chat immediately. If they have access to two or more, they land on a portal page listing those agents, and pick the one they need. Request the routing template or a live demo right after you validate your attribute strategy with IAM and the registrar systems team.Attribute Strategy and Minimization
Enrollment and course schedule data are commonly treated as education records in many institutions’ privacy posture. Under FERPA, “education records” can include items like class lists and student course schedules, which is why routing design should minimize what you send. The safest default is to pass a coarse course entitlement key such as biology-101, not a full schedule, section details, or a raw roster. If you can route with an entitlement key, you usually reduce compliance review friction and keep the implementation simpler. Your complexity switch is where the attribute comes from. If your IdP already has groups or claims that represent course entitlements, routing is mostly configuration. If not, you’re in “upstream sync” territory where SIS or LMS data must be turned into IdP attributes before this rollout can work.How End User IdP Login Works
End User IdP Login uses SSO to authenticate the student, then uses the IdP attribute value to decide which agent or portal view they’re allowed to access. This keeps the student experience simple while keeping access control centralized.- Portal flow: Visit → IdP login → routed to allowed agent or portal → chat
- Routing logic: One agent → chat now; multiple agents → portal picker
IdP Attributes Versus LTI
Many universities already have course context living inside the LMS, and LTI 1.3 exists to launch external tools from an LMS with a modern security model. If your “student AI” experience lives inside the LMS course shell, LTI-style launches can be a natural fit. IdP entitlement routing is usually better when your experience is a campus portal or student services hub where students arrive outside the LMS. It’s also often easier for IAM teams to operationalize, because access policy stays in the IdP and roles. A common hybrid posture is: SIS or LMS informs entitlements, then entitlements live in the IdP as course keys. That way, your chatbot path doesn’t need raw rosters, just the minimum routing signal.Student UX reality
Student ticket volume is rarely caused by “the model.” It’s usually caused by UX expectations that don’t match how SSO-gated, chat-only access behaves at scale, especially on shared devices or public lab computers. End User IdP Login sessions are time-bound, and students should expect to re-auth after the session expires. Students also shouldn’t expect persistent account features, because no CustomGPT end-user account is created for this access model. Conversation history between sessions is not retained for end-user access, so each session effectively starts fresh. This is a governance-friendly default, but it needs clear student-facing messaging so it doesn’t look like “the system lost my work.”Setup Snapshot
Admins configure End User IdP Login in My Profile → SSO tab, where you enter the IdP attribute name used for role mapping and copy the portal login URL to share with students. This assumes your Enterprise SSO is already set up. Routing is controlled by exact matching: the IdP attribute value must match a role name created in Teams → Roles, and that role should be configured as chat-only with only the intended course agent assigned. This is how biology-101 maps cleanly to the Biology 101 agent. When the mapping is missing or incorrect, students will authenticate but hit an “unauthorized” outcome rather than being shown agents they shouldn’t see. That’s the right failure mode, and it’s what you want to test in pilot. For ongoing access management, see how to update and revoke external agent access.Forward to IT Security
This is the concise proof layer most IT and security reviewers need: authentication protocol, access control model, session behavior, and access revocation. Forward it as-is to speed up approval without pulling engineers into a long thread.- End-user access is authenticated through the university IdP using SAML 2.0 SSO.
- Access and routing are driven by attribute to role mapping, with exact-match role names.
- Students get chat-only access, and no CustomGPT end-user account is created for them.
- Sessions are time-limited and require re-auth after expiry, supporting shared-device realities.
- Access removal is handled by updating IdP entitlements so the student no longer matches the allowed role.
Conclusion
If you want campus-scale AI without turning it into a new account-management problem, start with End User IdP Login and design routing around minimal enrollment entitlements. Research shows 88% of students now use generative AI for assessments in 2025, up from 53% in 2024, highlighting the rapid adoption that makes secure, scalable access critical. You’ll reduce public-link risk, keep access reviewable, and give students a predictable login experience. Success looks like students consistently reaching the right course agent via SSO with fewer access tickets, clear re-auth expectations, and no need for your team to manage student accounts inside CustomGPT. A Digital Education Council survey shows 86% of students now use AI in their studies, with 54% using it weekly or more, making secure, controlled access to campus AI a critical infrastructure decision. Planning a campus-wide rollout? Start your 7-day free trial to build course agents, then explore Enterprise options for SSO routing and role-based access.FAQ
No. Students must authenticate through your university identity provider, and access is limited to the agents allowed by their mapped role. CustomGPT does not create a CustomGPT end-user account for students in this model.
Use the portal URL rollout model because it’s designed for role-based routing and low support overhead. If your primary student entry point is inside the LMS, evaluate an LTI-style approach at the program level instead.
This usually means the IdP attribute value does not exactly match a configured CustomGPT role name, or the matching role is not assigned to any agent. Fix the role mapping and role-to-agent assignment before expanding the pilot.
If a student can authenticate but can’t chat, confirm the role is set to chat-only and actually includes the intended agent. Also confirm the student is landing in the correct agent from the portal, especially if they have access to multiple agents and must choose from the portal picker.
That’s an institutional policy decision. SSO can ensure only enrolled students access the system, but it doesn’t determine what uses are allowed in coursework.
This rollout does not provide detection controls. Universities typically address this through policy, assessment design, and approved tools, rather than trying to infer usage reliably.
Universities can sometimes detect patterns, but “detection” is not dependable enough to be the foundation of governance. This guide stays focused on access control, routing, and student UX expectations.