The Short Answer
A K-12 agent can safely run student code when its sandbox starts with no network at all. On ibl.ai each chat gets its own Linux VM, default egress none, opened only to an allowlist of exact host:port pairs — and you own all the code and the data.
A student asks the tutor to debug a Python function. To help, the agent has to run it — see the real traceback, find the off-by-one, show the fix. That is the difference between a tutor and a chatbot about tutoring, and it is where most district deployments stall.
Why does code execution stop K-12 AI deployments that tutoring alone would pass?
Because the question changes from "is the content appropriate" to "what can this process reach", and most platforms cannot answer the second one.
An agent that can run shell commands can, in principle, call an external API, read a mounted credential, or reach a system nobody scoped it against.
For a district bound by FERPA and COPPA, that is not a hypothetical to be managed with policy. The architecture permits it, and permitting it is the finding.
Content moderation does not help here. A district can screen every message in both directions and still be unable to say where a subprocess sent its output.
What can an ibl.ai agent's virtual machine reach on the network?
Nothing, until the district says otherwise. Every chat runs in its own isolated Linux VM — a real machine with its own kernel, not a container or a WASM shim — and it starts with no network. Each agent then takes one of four egress profiles.
| Egress profile | What the VM can reach | Typical district use |
|---|---|---|
| None (default) | No network at all | Running and grading student code |
| Registries | Package registries only — PyPI, npm, apt, apk | Coursework needing a library install |
| Public | The public internet, with private ranges, loopback and cloud metadata denied | Rarely appropriate for minors |
| Custom | Deny by default; only the hosts in a named network policy | SIS or LMS integrations |
A network policy is a named allowlist an administrator writes once and reuses across agents — never across organizations. Entries are exact host:port pairs, with no wildcards and at most 100 per policy; loopback, link-local and cloud metadata addresses are refused outright.
How does an agent use a SIS credential it cannot read?
Through VM secrets. Inside the virtual machine the secret's environment variable holds a placeholder. The real value is substituted only on encrypted requests to the hosts that secret is allowed to reach — so the agent can call the API and cannot print, log or leak the key.
For a district that means PowerSchool, Infinite Campus or Skyward credentials, and Canvas or Google Classroom tokens, are usable by an agent that can never extract them.
A secret can also point at a credential the organization already stores for an integration, so rotating it once updates every agent that uses it.
The platform checks the combination as well: secrets require the Public or Custom profile, and under Custom every host a secret may reach must also appear in the agent's network policy — a secret can never open a path the policy does not.
What does this let a district actually teach?
The things that need execution rather than description.
- Live debugging — the agent reproduces the student's error and walks through the fix in the terminal
- Programming assessment — submitted code runs against test cases inside the sandbox
- Data analysis — students work with real datasets while the VM keeps them from leaving it
All twelve of the pre-built K-12 agents can run in sandbox mode, alongside the platform's dual-layer moderation — every student message screened before it reaches the model, every response filtered before it reaches the student — with rules configurable by grade band (K-2, 3-5, 6-8, 9-12).
How does this map to what FERPA actually requires?
FERPA does not merely assume institutional control — under the school-official exception it conditions the exception on it.
34 CFR 99.31(a)(1)(i)(B) lets a district share education records with a contractor only where that party is "under the direct control of the agency or institution with respect to the use and maintenance of education records."
Direct control over a process you cannot see inside is a difficult thing to assert. The sandbox turns it into a property of the system rather than a clause in a contract.
COPPA is a different instrument and worth not conflating with it.
It regulates commercial operators of services directed to children under 13, and its mechanism is verifiable parental consent, direct notice, data minimisation and retention limits — not institutional control of records.
A school may act as the parent's agent only for the use and benefit of the school. And it says nothing about students aged 13 and over, which is most of a district's secondary population.
| The question a district has to answer | The control that answers it |
|---|---|
| Can student work leave the environment it runs in? | Default egress is none; a path exists only where an admin created one |
| Where exactly may it go? | An explicit list of host:port pairs, no wildcards, capped at 100 |
| Could a compromised agent extract our SIS key? | The key is never inside the VM — only a placeholder is |
| Can one student's session affect another's? | Each chat runs in its own VM with its own kernel |
| Who can change any of this? | Separate permissions for policies and secrets, held by admins by default |
Cost is bounded too: VM time is charged per second against the credits of the person chatting, at $1 per ten minutes by default — a figure each organization sets for itself, and can set to zero.
Why does ownership change the answer for a school district?
Because most K-12 AI tools are managed services where the execution environment belongs to the vendor. A data processing agreement can describe what the vendor promises; it cannot let the district inspect the boundary.
On ibl.ai you own all the code and the data. The platform runs under a perpetual license on district or state infrastructure.
It is model-agnostic, so a district can run an open-weight model entirely inside its own network with no external inference call at all — and pay with no per-seat pricing, which matters when the alternative is licensing every student.
Deploy anywhere: your cloud, your VPC, on-premise, or a fully air-gapped network.
More than 1.6M users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
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.
A tutor that can run code is a genuinely better tutor. The sandbox is what lets a district say yes to it and still answer the parent.
Related: Why AI Agent Security in K-12 Requires a Different Playbook — the governance side of the same problem, where the users are minors and the vulnerability rate is measured.