This page explains how NSIBRA protects the work that passes through GVP, Institution OS and the Sovereign Compute Node, what we can and cannot see, and the limits an institution sets. It is written so that an institution's IT or security officer can check our claims.
At a glance
- Identifying details are removed before any AI model sees a request.
- Where an institution requires its own node, work stops rather than leaving.
- We record that work happened, never what it said.
- Connections to the services are encrypted in transit.
- The institution sets who sees what, and what may be done.
- Breaches affecting personal data are reported to the Nigeria Data Protection Commission.
1. The Sovereign Compute Engine
No part of GVP sends work to an AI model directly. Every request passes through the Sovereign Compute Engine first, through four steps.
Inspect. The request is read before anything is sent, to find what in it identifies a person, an account or a reference.
Strip. Identifying details are replaced with placeholders, and restored when the work returns. Figures are left unchanged, so the work remains correct. If something looks like an identifier that cannot be safely replaced, the request is stopped and nothing is sent.
Route. Only the replaced text travels, and only to where the institution's policy allows. Where the institution has its own compute node, work goes there first.
Log. Each crossing is recorded on the institution's own record: when it happened, where it went, and how many details were removed.
2. The Sovereign Compute Node
An institution can run its work on a machine it owns, in a room it controls. Where the institution requires its node, work that cannot reach the node is stopped. It is never sent elsewhere without the institution's decision. Identifying details are still replaced on the node, so the institution's record is complete wherever the work ran.
3. What we can and cannot see
Our operational view of the services records that work happened, when, and how it was processed. It does not record what the work said. Work you produce is stored in your account so you can return to it. Screenshots, where an institution allows them, are read once and not kept.
4. Authority
By default, Act reads the page an officer sends it and reports what it finds, and goes no further. Anything beyond reading and reporting, including reading screenshots, is switched on by the institution for the roles it chooses. Inside Institution OS, each department has its own login, and each role reaches only what it is permitted to.
5. Checking the work
Figures in produced work are checked by independent models from different makers. Where GVP cannot confirm a fact, it marks it rather than guessing. This reduces errors; it does not remove them. Officers remain responsible for work they sign or send.
6. Model providers
The engine works with models from several leading providers. Each receives only the text of a request after identifying details have been removed. The current list, and where each provider processes data, is set out in each institution's agreement and is available on request. Where an institution has its own node and requires it, its work does not go to outside providers at all.
7. In transit and at rest
Connections to the services are encrypted in transit. Access to stored data is limited to what is needed to run the services.
8. What we do not yet have
NSIBRA is a young company, and we would rather say this plainly than let you find it. We do not yet hold independent security certifications such as ISO/IEC 27001 or a SOC 2 report. Until we do, an institution can ask us for written answers to its own security questionnaire, the list of model providers and where each processes data, and a walk-through of the engine and its record with its own IT or security team.
9. If something goes wrong
If a breach affects personal data, we will notify the Nigeria Data Protection Commission and, where required, the people affected, within the time the law sets.
10. Reporting a security weakness
If you believe you have found a security weakness in any NSIBRA service, write to contact@nsibra.com with the subject "Security report". Include what you found, where, and the steps to reproduce it.
Please do not access other people's data, keep any data you come across, or disrupt the services while testing. We will acknowledge your report, keep you informed as we fix it, and credit you if you wish.
11. Related
How we handle personal data is set out in our Privacy Policy. The rules for using the services are in our Terms of Use.