--- title: "Letting a K-12 AI Agent Run Code Without Letting Data Out" slug: "agent-sandboxes-k12-districts-code-execution" author: "ibl.ai Engineering" date: "2026-09-28 13:00:00" category: "Premium" topics: "K-12, agent sandboxes, FERPA, COPPA, student data privacy, STEM education, AI agents" summary: "An AI tutor that can actually run a student's Python is worth far more than one that can only talk about it — but only if the district can say where that code ran and what it could reach. Agent sandboxes answer that with a Linux VM that starts with no network at all." banner: "" thumbnail: "" linkedin: | A student asks their AI tutor to debug a Python function. To be useful, the agent has to actually run the code. That is where most K-12 deployments stop. Not because the tutoring does not work — because nobody can answer the superintendent's question: when the agent runs code, what else can it reach? On ibl.ai the answer is now a specific one. Each chat gets its own Linux virtual machine, and it starts with no network at all. Not a firewall rule added afterwards — no network is the default state, and opening it is an administrative decision. From there a district picks one of four egress profiles: none, package registries only, the public internet with private ranges and cloud metadata denied, or a named allowlist of exact host:port pairs — up to 100, no wildcards, reusable across agents and never shared between organizations. The part that matters most for a compliance officer: an agent can call the SIS with the district's API key without ever being able to read that key. Inside the VM the environment variable holds a placeholder; the real value is substituted only on encrypted requests to the hosts that key is allowed to reach. FERPA's school-official exception does not assume institutional control — it conditions the exception on it: 34 CFR 99.31(a)(1)(i)(B) requires the contractor to be under the district's direct control with respect to the use and maintenance of education records. Direct control over a process nobody can see inside is a hard thing to assert. An agent with unrestricted code execution breaks it architecturally — not because it will exfiltrate anything, but because nothing stops it. With ibl.ai you own all the code and the data, and now you also decide exactly what your agents' code can touch. #iblai #K12 #EdTech #FERPA #StudentDataPrivacy #AIAgents --- ## 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](/solutions/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)](https://www.law.cornell.edu/cfr/text/34/99.31) 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](/blog/ai-agent-security-k12-different-playbook) — the governance side of the same problem, where the users are minors and the vulnerability rate is measured.* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 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.