The approval answer
IT approves App Boundary, not a stream of unknown classroom apps.
A generated app can render the learner experience, read reviewed content, save progress, emit attempt events, and finish an attempt only through the runtime capabilities App Boundary exposes. It cannot hold LMS credentials, connect to the LMS directly, write grades on its own, or reach arbitrary services.
What IT is not being asked to accept
No arbitrary LMS access. No invisible production push.
- Generated app code does not receive raw LMS tokens.
- Generated app code does not receive database, storage, Worker, Durable Object, or service bindings.
- Generated app code does not write grades directly to the LMS.
- Generated app code does not make arbitrary outbound network calls.
- Generated app changes do not reach students until a reviewed version is approved and pinned.
Risks mapped to controls
The risks are direct. The controls should be too.
Risk
A generated activity becomes a broad LMS integration.
Generated apps do not receive LMS credentials. They run as browser packages behind App Boundary and call only the reviewed runtime surface.
Control
Capability checks, signed runtime contracts, and blocked direct grade-write paths.
Risk
A course tool writes grades without a governed path.
App Boundary owns scoring and grade publication. Apps can propose or finalize only through reviewed package settings and server-owned LMS service calls.
Control
Attempt records, grade publication records, retry evidence, and audit events.
Risk
Student work is stored in an unclear vendor path.
App Boundary separates normal progress from sensitive evidence. Progress, submitted artifacts, and preview activity are scoped to a reviewed app version and attempt.
Control
Purpose, data scope, retention, and sensitivity labels on the review surface.
Risk
AI-written code can call unknown services.
Generated packages are browser-first reviewed artifacts. Validation rejects arbitrary outbound network, Worker-shaped code, direct storage, and platform bindings.
Control
Package validation, TypeScript checks, preview assertions, and immutable snapshots.
Risk
No one can reconstruct what happened.
App Boundary keeps durable logs for generation, review, launch, runtime capability calls, evidence, and grade publication.
Control
Admin activity logs, runtime logs, preview evidence, and audit records.
Risk
A new classroom app creates a new procurement burden.
IT reviews the governed boundary. Instructors can create or revise apps inside that boundary without turning every activity into a new LMS integration.
Control
One LTI tool, reviewed versions, controlled placements, and explicit approval gates.
What reviewers can verify
The approval page shows the facts before students see the app.
Review is operational: what changed, what the app can do, how it behaves in a test launch, and why the package stays inside the boundary.
Approval path
What happens before an app reaches students.
- Generate or import The app becomes a package candidate, not a live LMS tool.
- Validate App Boundary checks package shape, TypeScript, capabilities, policy, and preview behavior.
- Review Reviewers inspect capabilities, accessibility evidence, runtime behavior, and sensitive actions.
- Approve one version Only an approved immutable version can be pinned to an LMS placement.
- Run behind the boundary Launches, progress, scoring, storage, evidence, and audit stay inside the governed runtime.
Bottom line
App Boundary is not asking IT to trust AI-generated code with the LMS.
It asks IT to approve one governed boundary where classroom apps are limited, reviewed, versioned, logged, and blocked from direct platform access.