MNPI and the Investment Bank: Air-Gapped AI for Material Non-Public Information

An investment bank can use AI over material non-public information, or MNPI, only when the model runs air-gapped on hardware the bank owns and controls, with every query and answer written to a signed, tamper-evident record. A hosted service cannot do this, because the moment MNPI leaves the bank to reach a vendor's servers it has crossed the information barrier the bank is legally required to maintain. The air-gap keeps the data inside the wall, and the audit ledger proves, deal by deal and person by person, exactly who touched what.

This matters in 2026 because banks are under pressure to deploy AI across research, coverage and deal execution while control functions have no clean way to let a model read the most sensitive data they hold. Compliance has therefore blocked AI at the barrier, the correct call for any hosted service. The real question is not whether to use AI on MNPI, but whether the architecture keeps the barrier intact and produces evidence a regulator will accept.

Why does hosted AI break the information barrier?

An information barrier, historically called a Chinese wall, separates the people who hold MNPI, such as an advisory team on a live transaction, from those who must not, such as sales, trading and research. A hosted AI service breaks this in two ways. First, the prompt containing MNPI is transmitted to a third party outside the bank's control, which is a disclosure. Second, the vendor's logs, caches and training feedback become an uncontrolled copy of that MNPI the bank cannot inspect, seal or prove was never queried by the wrong party. Under the US CLOUD Act, data held by a US-linked provider is also reachable by lawful process regardless of where the servers sit. A barrier you cannot see inside is not a barrier.

How does air-gapped AI let a bank use AI over MNPI?

Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on the bank's own hardware. Sovereign models sit inside the same controlled environment as the MNPI, so the data never travels to a vendor. The barrier is enforced in the architecture, not promised in a contract. The design rests on four mechanisms.

• A zero-egress inbound perimeter. The system accepts controlled inputs but has no outbound path to the public internet, so MNPI has nowhere to leak.
• Hardware-attested identity. Every user and device is cryptographically bound to the audit chain, so access is tied to a proven identity, not a shared login.
• A post-quantum signed audit ledger. Each query, document read and answer is sealed into a tamper-evident record using FIPS 204 and FIPS 203 signature and encapsulation standards.
• Deal-scoped access. The barrier is expressed as policy, so a model instance working a transaction cannot read across into data walled off from that team.

What can an auditor actually check?

An auditor can read the ledger directly and verify it offline, without trusting the bank's word that the log is complete. Because the record is cryptographically sealed, the signatures prove it has not been altered or back-dated. For any MNPI document, an auditor can answer: which identities queried it, at what time, from which attested device, what the model returned and whether that access sat inside or outside the relevant barrier. Pick a deal, pick a person, and the ledger reconstructs the full access history with a signature on every line.

“An information barrier is only real if you can prove, after the fact and to an adversary, exactly who accessed what.”

Which rules make this necessary?

Several regimes point the same way. The UK Market Abuse Regulation and the US securities laws require banks to prevent the misuse of inside information and to evidence their controls. DORA, in force across the EU since January 2025, holds financial firms accountable for the resilience and oversight of the technology and third parties in their critical operations, which a hosted AI service sits squarely inside. NIS2 raises security duties for essential entities, GDPR governs any personal data in the mix, and ISO/IEC 42001 sets a management-system standard for the AI itself. Air-gapped, sealed architecture directly addresses the shared requirement behind all of these, because it removes the third party rather than trying to contract around it.

What about the EU AI Act deadline?

The EU AI Act's high-risk obligations under Annex III were originally due on 2 August 2026. The Digital Omnibus deferred them to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028, while the Article 50 transparency duties remain largely unchanged. We read this as a build window, not a reprieve. A bank that stands up audited, air-gapped AI now will meet the high-risk logging and human-oversight expectations well before they bite, rather than retrofitting controls onto a hosted deployment never designed to be inspected.

How is this different from a private cloud tenancy?

A private tenancy still runs on a vendor's infrastructure under the vendor's operational control, and still depends on the vendor's promise that your MNPI is isolated. Air-gapped means the hardware, the models and the ledger all sit inside the bank's own boundary with no outbound path. The distinction is control you can prove versus control you are asked to trust, and for MNPI, where the obligation is demonstrable containment, only the first survives scrutiny. Cross-model consensus can raise assurance further: independent sovereign models check each other's output so no single model's error goes unnoticed, all recorded in the same sealed ledger.

Frequently asked questions

Can an investment bank legally use AI on inside information?

Yes, provided the AI processes that information entirely within the bank's own controlled environment and never transmits it to a third party. The legal risk is not the use of AI as such but the disclosure of MNPI outside the information barrier. An air-gapped, on-premise system removes that disclosure, and a sealed audit ledger evidences the controls a regulator expects.

Why can a bank not just use a public hosted AI service for deal work?

Public hosted services process prompts on the provider's own infrastructure, so any MNPI in a prompt leaves the bank and reaches that third party, which is a disclosure across the barrier. The bank cannot inspect or seal the provider's logs, and under the US CLOUD Act the data may be reachable by lawful process. Public cloud AI suits non-sensitive work, not material non-public information.

What does air-gapped actually mean here?

It means the AI runs on hardware the bank owns, inside its own perimeter, with no outbound connection to the public internet. Inputs are controlled and inbound only, so MNPI has no route out. This is stronger than a private cloud tenancy, because the bank controls the hardware and can prove containment rather than trust a vendor's isolation promise.

How does the audit record hold up if it is challenged later?

Every access is sealed into a tamper-evident ledger using post-quantum signature standards, FIPS 204 and FIPS 203, so the record verifies offline without trusting the bank. The signatures show the log was not altered or back-dated. For any deal or person, the ledger reconstructs who accessed which MNPI, when and from which attested device.

Does an on-premise AI system meet DORA and the EU AI Act?

Removing the third party directly addresses DORA's oversight and resilience duties, which are hardest to satisfy when a hosted vendor sits inside a critical function. For the EU AI Act, high-risk obligations were deferred by the Digital Omnibus to 2 December 2027, so standing up audited, air-gapped AI now positions a bank to meet the logging and human-oversight requirements ahead of time.