The Short Answer
A district should adopt the new OIDC sign-in and capability flags as they ship, and set the sandbox default deliberately: since November 6, 2026 new ibl.ai agents start with a VM on and public egress unless a tenant override says otherwise. Set it to off or none first, then open it per agent, on ibl.ai, where you own all the code and the data.
The November 6, 2026 platform update covered eleven services and packages, platform versions 1.356.0 to 1.398.0. Three of its changes land directly on the questions a district asks before it lets students near an agent.
How do students and staff sign in to an ibl.ai agent with the district's own accounts?
Through the identity provider the district already runs. The release rewrote the SSO module and added a GENERIC_OIDC provider, a catch-all for any identity provider that implements the OpenID Connect Core 1.0 specification.
For Microsoft districts there is a dedicated MICROSOFT_GRAPH provider: one Azure app registration that accepts both personal and work or school accounts from any Microsoft Entra tenant, resolving the email address from Graph.
Three details matter for a school system.
Disposable-email blocking now applies to accounts created through SSO and is on by default. SSO, magic-link and edX-proxy sign-in endpoints carry per-IP rate limits. And new SSO accounts take the identity provider's username when it is valid and free.
The practical effect is that there is no second set of passwords. When a student leaves the district, the account the district disables in its own directory is the account that reached the agent.
How does a district control which tools an AI agent is allowed to use?
With capability flags. Every agent and every session now carries capability_* switches that are the source of truth for which tools run, replacing the old tool lists while keeping their endpoints working.
The flag that matters most for minors is the immediacy.
Turning a capability off on an agent stops it on the next turn of existing sessions, not only in conversations started afterwards. A district that disables web search on a middle-school agent at 10:00 does not wait for students to log out.
The release also added capability_subagents, which gates whether an agent may hand work to subagents, and a per-agent switch for screen sharing in embeds. Web Search and Web Fetch are now a single capability, so one switch closes both.
| District question | What the November 6 release provides |
|---|---|
| Can students use their district accounts? | Generic OpenID Connect, plus one Entra registration for any tenant |
| Can we switch off a tool mid-semester? | Capability flags; off takes effect on the next turn of live sessions |
| Can an agent hand work to subagents? | Only where capability_subagents is on |
| Do new agents get a code sandbox? | Yes by default, with public egress; set per tenant |
Is a sandbox VM on by default safer for K-12 AI agents?
Not by itself, and this is the change to read carefully. When ibl.ai announced agent sandboxes on September 28, 2026, a VM started with no network by default.
As of November 6, new agents start with the VM on and public egress.
Public egress is not an open door: the profile still denies private address ranges and cloud metadata endpoints.
But it is a convenience default. For a district, convenience is the wrong default for agents students reach.
Two settings decide it: DEFAULT_MENTOR_ENABLE_VIRTUAL_MACHINE and DEFAULT_MENTOR_VIRTUAL_MACHINE_EGRESS, set globally and overridable per tenant.
A district sets its tenant to false, or to egress none, before anyone builds an agent, then opens each agent to exactly the hosts it needs.
Existing agents are not changed by the release.
The full egress model, from none to an allowlist of up to 100 exact host:port pairs, is set out in Letting a K-12 AI Agent Run Code Without Letting Data Out.
Why do identity and control decide FERPA's school-official question?
Because FERPA's school-official exception is conditional. Under 34 CFR 99.31(a)(1)(i)(B), one of the conditions a contractor must meet is being under the district's direct control with respect to the use and maintenance of education records.
Direct control is a claim about mechanisms. Accounts the district disables in its own directory, tools a district switches off in the middle of a live session, and a sandbox default the district chose rather than inherited are three mechanisms a district can point to.
Why does it matter when a school district self-hosts its AI agent platform releases?
Because the defaults above changed in a release, and a district should decide when a release reaches students. On a self-hosted ibl.ai deployment every change ships as an image tag the district pulls on its own schedule, with its own maintenance window.
On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
The AI was rarely what held a district back. Sign-in, switches and defaults were, and those are now the district's to set.
Related: Letting a K-12 AI Agent Run Code Without Letting Data Out — the four egress profiles and the secret model behind the sandbox default discussed here.
Related: Talk to Any ibl.ai Agent From Claude Code, Cursor or Claude Desktop — the other agent-access change from the same week.