Security and Privacy

This page describes the behavior of the GamiBot Moodle plugins. The Langflow, ingestion, Gami API and vector-storage services have their own configuration and data policies; confirm those with their operators before using real course material.

Credentials and transport

The administrator enters one shared Langflow API key on the Manager plugin's Basic settings page. Moodle stores it as a masked plugin setting and uses it for Clarify, Summarize and Quiz, including retained custom Langflow connections. The Gami API secret and ingestion webhook secret are separate settings. Restrict site-administration access, and review custom Langflow endpoints before saving a shared key because those endpoints receive it.

Keep Verify SSL certificates enabled and use HTTPS endpoints in production. The ingestion sender posts JSON with the configured webhook secret in the request body. It does not create an HMAC signature. The receiver must check that secret and protect the endpoint. The Moodle sender omits request bodies, endpoint URLs, secrets and response bodies from ingestion failure exceptions.

Course material and access

Only File and Folder activities in a course with its own GamiBot block are candidates for ingestion. Moodle checks course, section and activity visibility and evaluates date-only availability rules. Student-specific availability trees are excluded from the shared index. This determines what Moodle sends; it is not a per-student access check when a chat query retrieves indexed material. Configure and verify course filtering and student authorisation in the receiving/search service as well.

The upload notification contains file metadata and a Moodle web-service file URL. The receiver needs suitably scoped Moodle access to retrieve the file. Protect that access and avoid exposing the URL or its credentials in logs.

The durable Moodle queue stores module/course identifiers, content fingerprints and a hash identifying the configured destination. It does not store the endpoint URL, webhook secret or file contents. Failed deliveries remain queued for retry.

Deletion and retention

When an activity becomes ineligible, the last course-level GamiBot block is removed, or a course is deleted, Moodle queues a file_deleted notification. Deletion is asynchronous. Content can remain in the remote index until that notification is accepted and processed. A successful HTTP response confirms receipt only; verify deletion at the receiver before treating access as withdrawn.

The receiver should delete every vector associated with the Moodle site, course and module, tolerate repeated deletion requests, and process a module's deletion before later uploads. After an upgrade from an older version, arrange cleanup of historical vectors that Moodle can no longer associate with existing modules.

Set retention, backup, incident response and student-data procedures for Moodle and each remote service according to your institution's requirements. The Moodle ingestion queue does not define the remote index's retention period.

See Data ingestion for queue status and Moodle setup for administrator settings.