App Boundary

A safe runtime for LMS-connected learning apps.

Schools are about to get a flood of small AI-built course apps. Most of them should not be separate LMS tools with their own tokens, backend logic, and grading code. App Boundary gives institutions one trusted boundary for launch, policy, grading, review, and audit.

Why this needs to exist

Without App Boundary

  • Every app acts like its own LMS integration
  • More tokens, more custom setup, more review surface
  • Grading and roster behavior are hard to inspect
  • Failures are scattered across vendors and custom code
  • AI-generated apps become unreviewable sprawl

With App Boundary

  • The LMS launches one trusted tool
  • Apps run inside a governed runtime
  • Policy, review, grading, and audit stay in one place
  • Institutions can inspect what an app can access
  • Authors build the activity, not the integration plumbing

If every AI-built course app ships as its own backend, institutions will stop trusting the category.

Three enforced boundaries

The runtime

Apps don't run on your LMS and they don't run on their own backend. They run inside a sandboxed browser environment on an isolated origin, behind a trusted edge gateway.

Each launch crosses the same control path before an app can read context or submit activity.

01 Launch boundary

Edge gateway

A worker process at the edge validates every launch, manages sessions, and brokers all access to the LMS. Apps never see raw credentials. The gateway signs a short-lived bootstrap payload so each session starts with a verified, scoped context.

02 Execution boundary

Isolated origin

Each app runs on a separate origin inside an iframe with a strict content security policy. No outbound network requests. No access to camera, clipboard, geolocation, or other browser APIs. No web workers. No plugins. The browser enforces this at the platform level.

03 Policy boundary

Declared capabilities

Apps list what they need in their manifest: read launch context, read content, submit events, write local state. The gateway checks each call against the declared set. If an app doesn't declare a capability, the runtime won't serve it.

Real product screens

Admin view showing managed app packages with approval status, capabilities, and metadata
See what an app is, where it runs, and what it can access.
Preview runtime launching a flashcard app inside the governed browser container
Launch a real app package in the platform runtime.
Terminal showing the app package file tree and validation output
Apps are small versioned packages with a clear contract.

How you build one

A Lantern app is a small web app plus a manifest, content files, and preview fixtures.

Package shape

app/
  manifest.json
  dist/
    index.html
    assets/*
  content/
    activity.json
  preview/
    fixtures.json
    tests.json

Basic flow

copy the template
edit the UI and content
deno task app:preview path/to/app
deno task app:validate path/to/app
publish the reviewed package

Read the authoring docs or start from the template app.

Design principles

One trusted LMS boundary
The institution connects once. Every app runs through that single reviewed integration instead of managing its own LMS plumbing.
Safe by default
Apps declare what they need. The runtime enforces it. No raw tokens, no direct database access, no unrestricted network calls.
Small reviewable app packages
Every app is a static package with a manifest, content, and preview fixtures. You can read the whole thing before it runs.
Simple authoring for humans and LLMs
The authoring contract is small enough that a person or an LLM can build a working app from the template in minutes.