MITR, a security gate for organizations that use AI agents. Edition of 3 October 2026; English version of 16 October 2026.
MITR is not an AI agent; it is protection against mistaken and dangerous actions of AI agents. The gate sits between the agents and the organization’s information systems and checks every action before it runs: in enforce mode, an action does not pass until it is proven admissible under the organization’s rules. Every decision gets a receipt that can be re-verified without trusting the developer.
Organizations hand AI agents work with data, money and program code. Agents, both their own and those built by suppliers into accounting systems, CRM and email, carry on correspondence, prepare payments, change databases and release software. Under current law an agent is not a subject of law, so the organization answers for each of its actions to clients, owners and the regulator.
The figures on this page are given with the date of measurement and can be re-verified independently. As of 14 October 2026, one class of actions, file deletion, runs in enforce mode; the others run in advisory mode.
Who it is for. Organizations that trust AI agents with data, money and code: operators of critical information infrastructure, financial institutions, operators of state information systems and of personal data, companies with autonomous software development.
Why. The agent does not bear responsibility for its actions; the organization does. Regulators require control and proof, and the usual protection tools do not see an agent’s actions: it works inside the perimeter with the rights it was given.
How. MITR intercepts every action of an agent before it runs, proves its admissibility under the organization’s rules with an SMT solver and issues a receipt. In enforce mode, an action whose admissibility has not been proven is not executed.
For the head of the organization: AI agent actions as a matter of responsibility
This section is addressed to the chief executive, the business owner and members of the board: those who decide to deploy AI agents and answer for the consequences.
The agent acts but is not liable
An AI agent is not a subject of law: the parties to legal relations remain individuals, organizations and the state. An agent’s action is legally an action of the organization that used it, and the organization bears the consequences of a mistake: a leak, a wrong payment, deleted data. How this works under Russian law is described on the page who is liable for AI mistakes.
The usual protection does not see the threat
Antivirus, firewalls, data leak prevention and monitoring systems are built to find an outsider: malware, an intruder, someone violating access rights. An agent works inside the perimeter with the rights it was given, and its commands are correct in form. The danger is not in who acts but in what action is chosen.
The regulator holds the organization to account
The requirements for information protection, for the security of critical information infrastructure and for processing personal data are addressed to the organization, not to the agent’s supplier. In an inspection or a dispute, it will have to answer three questions: who allowed the action, under which rule, and what proves it.
MITR answers all three with a receipt that is produced automatically for every action of the agent.
How it works
The easiest way to explain MITR is a fuse box. A circuit breaker opens the circuit on overload before a fire starts, and it does so without an electrician, which is why nobody in the house thinks about the wiring. MITR plays the same role for AI agents: it sits in the break between the agent and the information systems and checks each action before it runs.
- The AI agent forms an action: sending an email, a payment, changing or deleting data, exporting information.
- MITR checks, before execution, whether the action complies with the organization’s rules.
- Admissibility proven. The action is executed, and a receipt is written to the log: what action was taken, under which rule, and when.
- Admissibility not proven. In enforce mode the action is not executed; in advisory mode the agent receives a warning; in both cases, a list of the violated conditions, so that the plan can be changed.
- An internal auditor or an outside verifier re-checks the log of receipts without trusting the gate’s developer.
Checking one action takes a few milliseconds. The agent does not have to wait for approvals, and the security team gets not assurances but a log it can verify.
What the organization gets
- Preventing damage instead of investigating it. In enforce mode, an action whose admissibility has not been proven is not executed. Protection starts with irreversible actions: deleting data, payments and sending information outside the perimeter.
- An evidence base for inspections and disputes. Instead of an explanatory note, the organization presents a sample of receipts: what actions the agent took, under which rules they were allowed, what was stopped and why.
- Freedom to choose AI suppliers. The gate does not care which model proposed an action, domestic or foreign, open or closed: it checks the action itself. Agents can be replaced without revising the protection.
- Your own rules. An admission rule is stored as a data file, and the security team adds or changes rules without rewriting program code.
How MITR covers the organization’s risks
Each risk that arrives with agents has a matching mechanism of the gate and a verifiable result.
| Risk | MITR mechanism | Result |
|---|---|---|
| An agent performs an irreversible action: deletes data, makes a payment, sends information outside the perimeter. | The action is checked before it runs; classes of irreversible actions are moved to enforce mode, and an unproven action is not executed. | Damage is prevented before the event rather than investigated after it. |
| An attacker plants an instruction in a document, an email or a web page that the agent reads (indirect injection). | What is checked is the action, not the agent’s intention: an inadmissible call stays inadmissible, whoever suggested it. | An attack through data does not turn into an action. |
| The organization is liable for the agent’s actions but has no evidence that they were lawful. | Every decision is recorded as a receipt: the action, the rule, the facts, the verdict and the time. Receipts are linked into a chain whose head is fixed daily by an external time witness. | The organization shows, with a sample from the log, that the agent acted under its rules. |
| The regulator requires control over the use of AI and protection of information, including at critical information infrastructure. | Admission rules limit the transfer of protected information and dangerous operations, and the log records every decision. | Compliance is confirmed by records, not declarations. |
| The supplier’s model is closed or hosted abroad, and its behaviour changes with every update. | The gate does not depend on the model: rules apply to the action, not to whoever proposed it. | Changing the AI supplier does not require revising the protection. |
| Approvals slow work down: the security team wants to approve every action, and the business wants to keep its speed. | A check takes a few milliseconds and replaces manual approval with a receipt. | The agent works without waiting, and the security team gets a report instead of a queue of requests. |
How IS 3.0 differs from the usual protection
Security of earlier generations (IS 2.0) assumes that the organization’s own employees work inside the perimeter and that threats come from outside. An agent removes that assumption: it is inside, it is not a person and holds no position, and its mistake, or an attacker’s instruction hidden in a document it has read, looks like a legitimate command.
| Usual protection (IS 2.0) | MITR (IS 3.0) | |
|---|---|---|
| What is protected | The network, workstations and employee accounts. | The agent’s action at the moment before execution. |
| What it looks for | An outsider: malware, an intruder, someone violating access rights. | An inadmissible action, regardless of who performs it. |
| How it decides | By indicators, signatures and access rights. | By proof: an SMT solver checks the action against the organization’s rules. |
| What the organization is left with | Events and alerts that need to be analysed. | A receipt for every decision, which an outside specialist re-verifies. |
MITR does not replace antivirus, firewalls and monitoring: they are still needed against external threats. MITR covers the layer that these tools cannot see by their design: the actions of the organization’s own agents with the rights they were given. The more of the work agents do, the larger the share of operations that passes through this layer.
More on the three generations of protection on the page IS 3.0: security of AI agent actions.
MCP+: the standard way of connecting agents, plus a proof and a receipt
AI agents connect to tools and information systems through the open MCP protocol (Model Context Protocol; see what MCP is). The protocol is like a standard socket: any agent can be plugged into any system, a database, email, an accounting program, a code repository. The protocol defines how to connect, but it does not answer whether a specific action is admissible.
MCP+ = MCP + a proof of admissibility before execution + a receipt after it
- MCP: agent → system. The agent’s call goes straight into the system: there is neither a permission nor a record that can be verified.
- MCP+: agent → MITR → system. The call is executed only after its admissibility has been proven, and every decision leaves a receipt.
For the agent, connecting through MITR is no different from the usual way: the gate answers over the MCP protocol like an ordinary server, and the open package installs as a wrapper around an MCP server that is already connected. For the organization, every call gets a permission and a trace.
What the MVP can do
The working version of MITR has run continuously since 24 April 2026: the actions of the institute’s coding agents and service bots pass through the gate. Below are the capabilities that the MVP already provides.
- Check before execution. An agent’s actions, such as deleting data, writing a file, sending a message, publishing, stopping a service or deploying code, are checked against the rules before they are executed.
- Introducing protection step by step. A mode is set for each class of actions: shadow (observation), advisory (warning) or enforce. Protection is introduced step by step and does not stop the work.
- A refusal with an explanation. When it refuses, the gate gives the agent the list of violated conditions of the rule and options for a fix, so the agent changes its plan instead of repeating an inadmissible attempt.
- Rules as data. An admission rule is stored as a data file. A new rule is added without changing the gate’s program code.
- Self-development. The gate extends its own vocabulary of recognized actions. A new rule is adopted only after it has been checked on the body of earlier actions, through the same gate and with a receipt.
- An evidential log. Decisions are linked into a chain of receipts. The head of the chain is fixed daily by an external time witness, and the decisions can be re-verified with your own solver, without the developer.
- Independence from the model. The gate does not care which model proposed an action: it checks agents from domestic and foreign, open and closed suppliers in the same way.
- Connection without rebuilding the agent. The gate connects over the MCP protocol, through an HTTP call from your own code, as a wrapper around an MCP server, or with one import into a Python agent. The open package keeps its log under GOST R 34.11-2012.
The deployment path
Deployment goes through six steps, and the agents’ work does not stop at any of them.
- Trial installation. A specialist installs the open package on their own machine without network access and checks the mechanism on their own scenarios.
- Survey. A list is made of the agents, the systems they are connected to and the actions they perform. Irreversible actions are singled out.
- Admission rules. The organization’s policy is translated into admission rules that the security team reads and changes without changing program code.
- Observation. The gate is placed in the break between the agents and the systems in shadow mode: actions are not held up, decisions are recorded. After 30 days, the organization gets a report: what actions were taken, which would have been stopped, under which rule, and what the share of false stops is.
- Enforcement. Classes of irreversible actions, such as deleting data, payments and sending information outside the perimeter, are moved to enforce mode one by one, once the share of false stops has been determined for each.
- Operation. The receipts become material for internal audit and regulatory inspections. For significant objects of critical information infrastructure and closed environments, the gate is deployed in the customer’s infrastructure.
Regulation and critical information infrastructure in Russia
Using AI agents does not release an organization from the existing requirements for information protection. The gate helps meet them where the action is performed not by an employee but by an agent. The names of the acts are our translation.
| Norm | Addressed to | How MITR helps |
|---|---|---|
| Federal Law No. 187-FZ “On the Security of the Critical Information Infrastructure of the Russian Federation” and FSTEC of Russia Order No. 239 | Subjects of critical information infrastructure: state bodies, institutions and Russian legal entities whose systems operate in healthcare, science, transport, communications, energy and the fuel and energy sector, atomic energy, banking and the financial market, state registration of real estate rights, and the defence, rocket and space, mining, metallurgical and chemical industries. | An agent connected to a significant object acts within the admission rules, and each of its actions is recorded. This supports the measures for access management and security event logging. |
| FSTEC of Russia Order No. 117, in force since 1 March 2026 | Operators of state information systems, state bodies, unitary enterprises and institutions. | The order sets requirements for the use of AI for the first time. An admission rule can forbid transferring protected information outside the system without grounds, and the log records every decision. |
| Federal Law No. 152-FZ “On Personal Data” | Operators of personal data, that is, practically every organization. | An agent’s transfer of personal data to an external service is an action of the operator. An admission rule can forbid it without grounds, and the receipt records the grounds. |
| Bank of Russia Regulations No. 851-P and No. 757-P | Credit institutions and branches of foreign banks (No. 851-P), non-credit financial institutions (No. 757-P). | The actions of agents in the loop of financial operations are checked before execution and recorded. |
The list was checked against the current versions of the acts on 3 October 2026. This is a reference to the norms in force, not a legal opinion: the organization decides whether it applies to a specific system. An analysis of Order No. 117 is on the page FSTEC Order No. 117 and artificial intelligence.
Position in the market
- What it is: an infrastructure layer of trust between the environment where an action is conceived and the environment where it is executed.
- What it is not: MITR is not a second supervising neural network, a text filter, or a replacement for antivirus and network protection.
- Who it is for: organizations that connect AI agents to their data, money and code and answer for their actions to clients, owners and the regulator. A private user does not need the gate: they set up their agents themselves and answer only to themselves.
- Horizon: by 2027–2030, a large part of information exchange will move to the internet of agents: agents of different suppliers will call each other and the systems of organizations without a human. The less human there is in the chain, the more important a proof at every step becomes.
- Neutrality: the proof does not depend on where the model comes from. MITR checks the actions of domestic and foreign, open and closed agents in the same way, and requires trust only in the rules the organization has set itself.
- Who stands behind the method: the ANO Scientific Research Institute of System Synthesis, the author of the method and the holder of the open code. Priority for the verification method is secured by invention application No. 2026116990 of 1 June 2026.
This page deliberately does not claim that “there are no analogues”: the market for AI protection tools in Russia has taken shape. MITR is distinguished by what it checks: the action is checked, the decision is made by a solver, and an outside specialist re-verifies the receipt.
For the security specialist and the architect: design, protocol, verification
This section is addressed to the head of information security, the information systems architect and the security engineer to whom the head of the organization sent this page. It sets out what exactly is checked, how the gate is connected, what it returns, how it behaves on failure and where the limits of its applicability lie.
What is checked
The gate checks not the model’s text but the tool call: the name of the action, the arguments, the recipient and the observed facts. The model’s reasoning is probabilistic and is not governed by rules; a call is discrete, so its admissibility is decided formally and before execution. Supervising one model with another is rejected by design: the supervising model has less variety than the one it supervises (Ashby’s law of requisite variety), and its verdict is itself probabilistic.
How a decision is made
- An admission rule (contract) is a data file that sets out premises, a safety condition and a class of action. An SMT solver proves that, given the facts passed to it, the action does not violate the safety condition. If no proof is obtained, the action is not admitted. How such a proof works is explained on the page formal verification and the Z3 solver.
- One of three modes is set for each class of actions: shadow (the decision is recorded, the action is not held up), advisory (the agent receives a warning) or enforce (an unproven action is not executed).
- The gate’s answer contains the verdict and, on refusal, a list of the violated conditions of the rule and options for a fix. A receipt is attached to the answer with a sequence number and a hash linked to the previous record.
- The gate extends its vocabulary of recognized actions itself: the gate adopted the first rule of its action vocabulary on its own on 25 September 2026, after a run on the body of earlier actions, through its own check and with a receipt.
Behaviour on failure
- A failure of the check inside the gate leads to a refusal: the action does not pass even when it was an error that prevented the proof.
- An action that the rules did not recognize is considered unproven. At present it is recorded and sent for vocabulary review; a default ban for such actions is in development.
- If the gate is unavailable for a class in enforce mode, that means a refusal, not a pass; making this rule hold at every connection point is in development.
Measured figures
| What was measured | Date |
|---|---|
| A decision on one action in a warmed-up process: median 0.87 ms, p99 6.0 ms; the whole call including an explanation: median 4.4 ms, p99 21.6 ms. A series of n = 1,000 (500 admissions and 500 refusals), 19 rules, 4 cores; on the reference set, 0 false admissions and 0 false refusals. | 2 October 2026 |
| Replay of decisions with an instrument designed for an outside verifier: an independent SMT-LIB solver over the texts of the rules stored next to the chain; 2,820 records, 2,814 matched, 0 discrepancies, 0 non-replayable; another 6 are refusals on a check failure, as they should be. | 3 October 2026 |
| The head of the receipt chain is fixed once a day by an external time witness (OpenTimestamps); as of 3 October 2026, 12 daily anchors, chain length 2,820, integrity holds; the anchors and the verifier are published openly. | 3 October 2026 |
| The gate’s core has run continuously since 24 April 2026. | 24 April 2026 |
| An admission rule is a data file: a new rule is added by editing the file, without rewriting the program. | 20 September 2026 |
| The gate answers over the MCP protocol with token authorization. | 20 September 2026 |
The measurements were made on the institute’s own environment. The spread of latency under industrial load is determined on a joint test bench. Later measurements, of 14 October 2026, are given on the page IS 3.0: a decision under a rule, 0.95 ms (median, 19 contracts); a replay of 4,958 decisions out of 4,958.
Connection
- Over the MCP protocol: the gate connects as an ordinary MCP server; the address and token are issued at deployment.
- Through an HTTP check call from your own code before the action is executed, with the same answer and the same receipt.
- As a wrapper around your own MCP server, with the open package mcp-sentinel; the quick start is below.
- With one import into a Python agent, with the open package iss-agent-kit.
Where the data are kept
The trial packages run entirely on the specialist’s machine: without a network, without an account and without contacting the institute’s servers. Where the gate is hosted at deployment is agreed with the customer; for significant objects of critical information infrastructure and closed environments, the gate is deployed in the customer’s infrastructure.
What is presented to an auditor
The auditor is given a sample from the chain of receipts: the action, the rule, the facts, the verdict and the time. The integrity of the chain is recomputed by an open verifier on the Python standard library, without installing the institute’s software. The anchors of the gate’s chain and the verifier are published at asi5.ru/console/verify/; the steps are on the page independent verification protocol.
Limits of applicability
- MITR proves the admissibility of an action given the facts passed to it; the facts themselves are established by the customer’s sensors and systems. A wrong rule leads to a provably wrong admission, so the quality of protection is determined by the quality of the rules.
- The gate does not check the model: the reliability of text, the quality of answers and backdoors in the weights are outside its subject.
- The open packages check a call by pattern matching, without a solver; the solver and the chain of receipts with an external time witness are part of the full gate.
- The open package’s log: the chain detects editing, deletion, insertion and reordering of records; to also rule out a complete rewrite of the log by its owner, the head of the chain is fixed with an independent party.
- The gate has no certificate of conformity. It is not required for protecting one’s own development environment; at significant objects of critical information infrastructure, the established procedure of software conformity assessment and system certification applies.
The architecture of the gate and its rationale, the classes of irreversibility, the checking loop and the invariants, are set out on the page MITR: architecture and rationale (in Russian).
What to check in an hour
- Install the package without network access and make sure a destructive database query is stopped; the commands are in the quick start below.
- Wrap your own MCP server and see what reason for a refusal the agent receives.
- Recompute the package’s log with the single-file verifier and make sure that editing one record breaks the chain.
- Recompute the anchors of the full gate’s chain from the data published at asi5.ru/console/verify/.
- Check the limits of applicability, and ask the questions this page does not answer through the contact form (in Russian).
Trial packages: open code, no registration
A specialist installs the three open packages on their own machine in a few minutes, including without network access. Every file is certified with a checksum, and the source code is published.
mcp-sentinel: protecting MCP calls
A wrapper around an MCP server with four rules: limiting the file system to the working folder, forbidding destructive database queries, intercepting leaks of secrets, and a barrier against dangerous shell commands.
Open source · Apache-2.0 · mcp-sentinel 1.1.2
mcp_sentinel-1.1.2-py3-none-any.whl · sha256: 681a4db59a1a44e89a2b1386ec4b4f2e1fc23c1025c295b9ebf00fd5d20901ea
mcp_sentinel-1.1.2.tar.gz · sha256: abb88978db7b34a2f1f56e0eff42bcd1365b9cc0eb17e4a4380f7815e4f1b79e
Source code: https://git.isslab.ru/isslab/mcp-sentinel
Measurement: checking contracts in memory, median 0.015 ms; a full cycle including writing the decision to the log on disk, median 22.5 ms (N=100).
The contradiction: an agent must act freely to solve tasks, and each of its actions must be guaranteed safe. The TRIZ resolution: the model’s thought stays free, while a discrete tool call is checked separately from it: the open package checks the call and the tool’s response against the given rules and returns the reason for a refusal to the agent, so that it does not repeat the inadmissible action.
iss-ledger-117: a log under GOST R 34.11-2012
A log of decisions linked with the “Streebog” hash function, and a single-file verifier for an isolated machine.
Open source · Apache-2.0 · iss-ledger-117 1.1.1
iss_ledger_117-1.1.1-py3-none-any.whl · sha256: 8d4ffe60f41ebd377c476f369655aaef5e0ac91858a3d294be37fd1e3100bc87
iss_ledger_117-1.1.1.tar.gz · sha256: 6eccef523e24fa60fed29c78866ff12afbab092bd17d51642e00d34dfcea9fa5
iss_verifier.py · sha256: 1ff894574407307d33ec99115652bcaec4e53d06189178696d0db1c767a8608f
Source code: https://git.isslab.ru/isslab/iss-ledger-117
Measurement: the GOST test vectors from RFC 6986 (M1, M2) pass; a stand-alone single-file verifier for isolated environments.
The contradiction: an audit log must carry evidential weight for the regulator, and it must not depend on closed trust servers and external suppliers. The TRIZ resolution: a chain of receipts under GOST R 34.11-2012 in pure Python with no dependencies; its integrity is recomputed by a single-file script in an isolated environment, without trusting the developer.
Quick start: connecting protection to your own MCP server
A vulnerable MCP server is not started directly; it is wrapped in mcp-sentinel wrap, and every tool call is checked before it runs, and the server’s response before it is passed to the agent. The package is written in pure Python with no third-party dependencies and installs without network access.
Installation
# isolated environment: the .whl files were downloaded in advance, no network needed
pip install --no-index --find-links ./wheels mcp-sentinel
# with network access
pip install --find-links https://isslab.ru/wp-content/uploads/iss-utils/index.html mcp-sentinelConfiguration for Claude Code or Cursor: claude_desktop_config.json or ~/.cursor/mcp.json
{
"mcpServers": {
"postgres-secure": {
"command": "mcp-sentinel",
"args": ["wrap", "--ledger", "/var/log/fstec117_audit.jsonl", "--agent", "claude-code", "--",
"npx", "-y", "@modelcontextprotocol/server-postgres", "postgresql://user:pass@localhost/prod"]
}
}
}Checking one call from the console
mcp-sentinel check --tool sql_query \
--args '{"query": "DROP TABLE users;"}'
# BLOCK: the destructive DROP TABLE operation is stopped, exit code 2A Python agent: connected with one import, the iss-agent-kit package
from iss_agent_kit import AgentGuard
guard = AgentGuard(ledger_path="/var/log/agent_gost.jsonl")
result = guard.run(execute_sql, "sql_query", {"query": "SELECT id FROM users WHERE id = 1;"})Open source · Apache-2.0 · iss-agent-kit 0.1.1
iss_agent_kit-0.1.1-py3-none-any.whl · sha256: 7ed0ae9073f512a5cfd71b62904094ca36d0ae2fdb1b4bfff5900d3e368781c3
iss_agent_kit-0.1.1.tar.gz · sha256: 0314047404888c29a231fc8710874f15bc2bd75e2b89ba7c4c882da3c792116a
Source code: https://git.isslab.ru/isslab/iss-agent-kit
The commands in this section are run when each version is accepted, in a clean environment without a network, with the same lines as printed here. The log at the –ledger path is kept as a chain under GOST R 34.11-2012 and recomputed by an external verifier without installing anyone else’s software.
Where to start
The first step is a trial installation by a specialist and a conversation about deployment. Observation over 30 days runs without stopping the agents’ work and ends with a report based on the receipts: what actions were taken, which would have been stopped, under which rules, and what the share of false stops is.
Discuss deployment (contact page in Russian).
ANO Scientific Research Institute of System Synthesis. Edition of 3 October 2026. Figures are given with the date of measurement. The IS 3.0 roadmap and the institute’s product line are on the page isslab.ru/cyber/ (in Russian).