Security

An AI platform on school machines has to survive being examined closely.

Invigilo is the software a school installs. Vigila and LUCA are modules inside it, and both touch some of the most sensitive material a school has: what a student is doing while something is at stake. Here is what we do about it: without technical language, and without promises we cannot keep.

In practice

Four things that hold across the platform.

Invigilo is built to what GDPR asks of exam monitoring: collect as little as possible, keep it separated, and be able to account for every look. The points below are not intentions: they are how the platform is set up today, and they hold for every module, not only the exam one.

No new passwords

Everyone signs in through your school's national login system, the one students and staff already use. Invigilo has no password of its own to forget, share or leak.

The student has no name with us

A student appears as an anonymous seat, never as a name or a national ID number. The link between seat and person exists only in your own roster, including when the work happens in the study module.

Your data is yours alone

One school's data is walled off from every other school's down in the database itself, not just in the software on top. And student work is not used to train a language model, not ours, not anyone else's.

An empty school computer room, screens and keyboards on long wooden desks, winter light through the windows behind — Your machines. Your data. Your key.

Only you can open the evidence

When an exam is exported as documentation, it is locked to your school's own key. Nobody else can open it, Invigilo included.

Vigila is built and running in closed testing ahead of a Q4 2026 launch. LUCA is in development. The points above describe how the platform is built today, not a service already in production.

See what the modules do

The precedent

A government's own exam-monitoring software was taken apart in an afternoon.

There is a well-documented case where a European government shipped its own exam-monitoring software with a hardcoded, placeholder encryption key: the digits one through eight in order. A student took the whole thing apart in an afternoon. A placeholder is what you type while you build. No finished system should ever ship with one. That case is the standard any school is right to hold us to, and the sheet beside this is our answer on the three points it failed.

That is why we are looking for the first schools to run Vigila through closed testing with, before the module is released: the three points have to be checkable by someone outside the company, not only by us.

That system

Invigilo

01 · The key to the material

That system

The digits one through eight, the same for everyone.

Invigilo

Documentation is encrypted to the school's own key. We cannot open it ourselves.

02 · What staff could see

That system

Spot checks into students' screens while the exam ran.

Invigilo

Nobody can browse a student's screen. Only what a rule has flagged can be opened.

03 · Who found the flaw

That system

A student, not the vendor.

Invigilo

We cannot promise we will always find it first. We can promise what happens next.

Honestly

Nobody can guarantee an exam tool can never be worked around.

That includes us. Software running on the machine a student is sitting at can always, in principle, be challenged by someone persistent enough. An academic security researcher reviewing the case above said much the same at the time: this kind of software cannot be made unbeatable.

So it is worth being wary of a vendor promising the opposite. A claim of an unbreakable system is either ignorance or sales talk, and both become the school’s problem the day it stops holding.

What we can promise

We respond fast: When a new way around the system surfaces, we close it and say what happened. We do not wait for the next scheduled release.
You hear it from us: The school should know what is monitored and what is not, from us, not from a headline.

Proportionality

No staff member can browse what a student is doing.

Spot checks helped end the system above, and rightly so: being able to look is not the same as needing to. Invigilo does not have that capability. There is no place in the system where you can follow a student live or read a raw feed of activity.

Only what was flagged: Staff see a finding because a rule flagged it. Everything else is out of reach, for us too.
Every look is logged: If a staff member opens the evidence behind a finding, the log records who and when. The school can read it itself.
A seat, not a person: What staff see hangs off a seat number. The name exists only in your own roster, never in our system.

The same principle holds for the study module: a student's conversation with the study model is the student's own, and does not become a monitoring trail a teacher can browse.

For your IT department

Technical summary.

The same facts as above, in the form an IT lead usually expects them.

01Identity and sessions OIDC jose JWT: OIDC against your national school identity provider. Sessions are JWTs signed with jose, set in httpOnly/secure/SameSite cookies with an eight-hour lifetime.
02Data separation Postgres RLS: Postgres Row-Level Security per institution, enforced in the database rather than in the application layer.
03Transport and browser TLS CSP HSTS: TLS with automatically renewed Let’s Encrypt certificates. Per-request nonce-based Content-Security-Policy on page responses, plus HSTS, X-Content-Type-Options, X-Frame-Options and Referrer-Policy.
04Exam codes timingSafeEqual: Compared with timingSafeEqual, so response time cannot be used to derive the code.
05Export and audit trail Per-institution key Audit log: Exported evidence is encrypted to the institution's own key. Read access to findings is logged per look.