A pilot of MITR at a customer: the delivery set, the site and the timing
A pilot tests MITR on the actions of the customer’s agents without stopping their work. For the first thirty days MITR only observes and writes receipts. Then irreversible classes of actions are moved into enforce mode one at a time, and the customer receives a report that its security team recomputes without the institute.
This page describes what already works in the institute’s installation of MITR and the order in which it is moved to the customer’s site. Everything that the institute’s installation does not have and that depends on the site is marked with the words “agreed during the survey”.
The delivery set
| What is delivered | Purpose |
|---|---|
| The checking service, MITR | The solver Z3 (an open project of Microsoft Research) proves the admissibility of each action under a contract. A mode of observation, warning or enforcement is set for each class of actions, and on a refusal the agent receives the list of violated conditions and options for a fix. |
| Connecting the agents | MITR connects over the Model Context Protocol (MCP) as an ordinary server, through a check call from a service’s code, as a wrapper around an MCP server or with one import into a Python agent; the method is chosen during the survey. |
| Contracts from the customer’s regulations | The institute translates the regulations into contracts, the translation is checked by a back-translation into natural language, and each contract is signed by an authorized specialist of the customer. The contracts remain the customer’s property. |
| The receipt chain and the verifier | Every decision produces a receipt with the action, the rule, the facts, the verdict and the time. The receipts are linked into a chain. A single-file verifier on the Python standard library recomputes it without installing the institute’s software. |
| The report on the observation period | The report, built from the receipts, names the actions that were taken, the actions that would have been stopped, the rule for each of them and the share of false stops. |
| Open packages for engineers | The customer’s engineer installs the mcp-sentinel, iss-ledger-117 and iss-agent-kit packages with their checksums before the pilot, without network access, and sees the method on their own scenarios; the packages contain neither the solver nor the chain with an external witness. |
Site requirements
- A server or a virtual machine inside the customer’s perimeter: the speed of a decision was measured on four server processor cores and eight gigabytes of memory. The headroom for industrial load is determined on a joint bench.
- Neither graphics accelerators nor internet access are needed for a decision: the solver runs on a processor and makes no call to a language model, so the check of an action does not leave the perimeter.
- Position in the network: MITR sits in the break between the agents and the target systems, the keys to the target systems are issued to MITR, and the agent keeps only the right to request a check. Reconciling the systems’ logs with the receipt chain reveals any request that bypassed MITR.
- The operating system, the requirements for certified protection tools and the place and period of storing receipts are agreed during the survey.
What the customer provides
- A list of the agents, the systems they are connected to and the actions they perform: from it the survey singles out the irreversible actions.
- The regulations and policies from which the contracts are written, and an authorized specialist who signs each contract after the back-translation check.
- Fact observers, that is, the customer’s systems from which MITR takes the facts for a proof: a directory of permitted payment recipients, a list of allowed addressees, an accounting system. MITR does not accept facts from the agent’s words. The set of observers is determined during the survey.
- Access keys to the target systems, which are handed to MITR, and a site that meets the requirements above.
- A contact person in the security team who receives the report and recomputes the receipt chain with their own tool.
A timestamp in a closed environment
The receipt chain detects editing, deletion, insertion and reordering of records, but only an independent party that fixes the head of the chain rules out a complete rewrite of the log by its owner. In the institute’s own installation this role is played by the external time witness OpenTimestamps. Once a day the head of the chain receives a timestamp in the Bitcoin blockchain, and an outsider checks it with the open client.
In a closed environment without internet access, the way of fixing the head is chosen during the survey. The hash of the chain head is carried by hand to an external node and fixed there with the same OpenTimestamps timestamp, or it is fixed by a time-stamping service that the customer designates; until then the records are protected only by the chain. In both options only the hash leaves the perimeter, and the receipts themselves stay with the customer.
Timing by stage
| Stage | What happens | Timing |
|---|---|---|
| Trial installation | The customer’s engineer installs the open packages without network access and checks the mechanism on their own scenarios. | Before the pilot, at the customer’s discretion |
| Survey | A list of agents, systems and actions is drawn up, the irreversible actions are singled out, and the connection method and fact observers are chosen. | Set by the size of the perimeter and fixed in the contract |
| Contracts | The regulations are translated into contracts, the translation is checked by back-translation, and each contract is signed by an authorized specialist of the customer. | Agreed on the results of the survey |
| Observation | MITR runs in observation mode: the agents’ actions are not held up, and every decision goes into the chain as a receipt. | Thirty days |
| Report | The customer receives the report built from the receipts and recomputes the chain with its own tool. | At the end of observation |
| Enforcement | Classes of irreversible actions are moved into enforce mode one by one, once the share of false stops has been determined for each. | One by one, at the customer’s decision |
| Operation | The receipts become material for internal audit and regulatory inspections. | Under a support contract |
Terms
The price of a pilot is not on the site: it is set after a conversation about the perimeter, not before it. A pilot is arranged by a contract with the operating company that receives a license to the institute’s developments, and the parties sign a non-disclosure agreement before any materials are handed over.
MITR has no certificate of conformity. At significant critical information infrastructure facilities, the established procedure for confirming the conformity of software and certifying the system applies, and a pilot does not replace it.
Contact
A conversation about a pilot begins with a letter to info@isslab.ru or a message to the scientific director on Telegram, @afischuk, with the subject “Pilot”. The design of MITR, its protocol and the limits of applicability are set out on the page “MITR”, and the measurements with the commands to repeat them are collected in the verification passport of information security of the third generation (IS 3.0).
Autonomous Non-Profit Organization “Scientific Research Institute of System Synthesis”, edition of 26 October 2026. This page is for information only and is not a public offer: the terms of a pilot are set by contract.