Overview

OpenMAIC treats uploaded files, fetched pages, provider capabilities, course documents, learner records, and agent sessions as different trust and ownership surfaces. Session-scoped materials preserve provenance; observed-origin and redirect checks bound web fetching; extracted content remains untrusted data rather than instructions. Browser-only storage offers a simpler private posture, while server-backed persistence adds continuity but requires authentication, authorization, quotas, retention, and deletion policy. These mechanisms expose deployment choices; they do not automatically make sources factual or development defaults safe for the internet.

Learning outcomes

Session-scoped material storage protects provenance and access boundaries, but extraction or fetching does not establish source truth.
Fetched content is untrusted data; origin, redirect, network, size, and content checks constrain the path without treating page instructions as commands.
Server-backed continuity requires real identity and operational policy; a public development token is not multi-user isolation.

Keywords

OpenMAICmaterialsprovenancestorageauthenticationnetwork

Trust Boundaries Around Materials, Models, and Storage

OpenMAIC's agent can only build responsibly from materials and services whose boundaries are understood. This chapter follows a source file or web page from session binding to extracted content, then compares the browser-only and server-backed ways the resulting course and learner state can be stored. The practical judgment is not simply whether a provider is supported. It is whether the deployment keeps source provenance, network access, ownership, runtime state, and optional capabilities separate enough for the intended users.

From bytes to scoped material

An uploaded file does not become prompt text by magic. In the session-materials path, the source bytes are stored under a session-specific prefix and the durable material row records metadata such as the original name, media type, and object keys. Extraction can later create readable text or derived media. The agent sees material identifiers and uses typed material tools to list, extract, read in pages, search literal text, or reuse media. The full source does not need to be placed in every model prompt.

That separation gives a material a lifecycle. A source can exist before its extraction is ready. An extraction can have a text object and derived images. A web page can be saved as a reusable web material with its title, source URL, fetched time, and bounded markdown. If a write fails ambiguously after bytes have been stored, the adapter checks whether the metadata row actually committed before deleting the object. That ordering matters: cleaning up too aggressively after a database timeout could leave a durable material pointing at missing bytes.

erDiagram OWNER ||--o{ AGENT_SESSION : owns AGENT_SESSION ||--o{ SOURCE_MATERIAL : binds AGENT_SESSION ||--o{ OBSERVED_ORIGIN : trusts SOURCE_MATERIAL ||--o{ DERIVED_CONTENT : extracts DERIVED_CONTENT }o--|| ASSET_BYTES : stored_as OWNER ||--o{ COURSE_DOCUMENT : authors AGENT_SESSION }o--|| COURSE_DOCUMENT : builds COURSE_DOCUMENT ||--o{ LEARNER_SESSION : supports LEARNER_SESSION ||--o{ RUNTIME_RECORD : appends PROVIDER_CAPABILITY ||--o{ AGENT_SESSION : enables OBSERVED_ORIGIN ||--o{ SOURCE_MATERIAL : permits_fetch

The session scope is important for both privacy and reasoning. A material bound to one session should not become a general object that another session can read by guessing an identifier. Owner-library uploads are checked before they are copied into a session, and the copied bytes remain addressable under that session's prefix. A stale or foreign object key resolves as a miss rather than opening another session's content. This is a storage boundary, but it is also a provenance boundary: the agent can be told which material was made available to this run.

Web content adds a second source of risk because the agent is not only reading bytes; the server is making an outbound request. fetchurl therefore does not accept every URL that appears in a model response. It requires an origin that was already observed in a user message or surfaced by a web-search result.

Published by DeepMox

FAQ

How does OpenMAIC keep uploaded materials scoped to a session?

OpenMAIC stores uploaded bytes under a session-specific prefix, checks owner-library access before copying, and exposes them through typed material tools. A stale or foreign object key resolves as a miss rather than opening another session’s content.

Why does OpenMAIC restrict which URLs the agent can fetch?

OpenMAIC restricts fetching to origins observed in user input or web-search results so a page or model response cannot silently widen the trust scope. Redirect, DNS, scheme, port, and private-target checks further limit server-side requests.

Is OpenMAIC's server-backed development setup safe for multiple internet users?

No. OpenMAIC's public development persistence token provides no meaningful user isolation, so an internet-facing multi-user deployment needs server-controlled authentication and authorization, plus data and network policies.

Previous9 minOpenMAIC: Typed Tools for Course Editing

Next10 minOpenMAIC: What Changes—and What It Cannot Guarantee

OpenMAIC: Trust Boundaries for AI Courses

Trust Boundaries Around Materials, Models, and Storage

From bytes to scoped material

FAQ