The post has been translated automatically. Original language: Russian
Evgeny Seisebaev is the author of SCRO+AI.
The development of artificial intelligence has posed a fundamentally new problem for digital systems. Previously, executable code was usually required to affect a computer: a program, a macro, a script, a malicious attachment, or the exploitation of a technical vulnerability. Now the control element can be an ordinary phrase in natural language, placed in a letter, contract, table, image, QR code or other document.
Such an instruction may be invisible to humans. For artificial intelligence, it can be understandable and convincing. If the AI only analyzes the document, an erroneous conclusion may result. If it is connected to mail, repositories, registries, file creation tools and other agents, the hidden instruction gets the opportunity to switch from words to actions.
A legitimate question arises for developers: how to protect the system if it is impossible to manually check every page of every document and it is impossible to guarantee that the AI itself always recognizes deception?
Most of the existing approaches seek first of all to detect a threat and not allow the model to obey it. The developed SCRO+AI comes from a different, more rigid premise:
the threat may not be detected, and the AI may be deceived — but the system must still maintain the boundaries of authority, the reliability of history, and manageability of decisions.
That is why the SCRO+It is more accurate to compare AI not with an antidote that destroys a malicious element, but with a fortress that does not allow it to take control.
The desire to recognize the enemy
The traditional approach to protection against prompt injection is largely based around recognition.
The system is trying to determine:
• does the document contain a suspicious command?;
• does the text attempt to override the system instructions;
• Are there any invisible fragments;
• does the document require disclosure of data;
• is he trying to get the AI to call the tool;
• is the malicious instruction transferred to the result?;
• whether the behavior of the model differs from the expected one.
To do this, filters, classifiers, lists of prohibited expressions, separate verification models, behavior analysis, and warnings to the user are used.
All these measures are useful. They are able to stop some attacks, reduce their likelihood and attract the attention of a specialist in a timely manner. However, they have a fundamental limitation.: they try to recognize malicious intent within the same semantic space in which the attacked AI operates.
An external document may contain plain text, legal wording, official instructions, a quotation, an appendix, or a technical description. The same text may contain a command addressed to the model. For language AI, both the content of the document and the control instruction are presented in a similar form — a sequence of words, symbols, or images.
The task of protection boils down to trying to correctly identify each time.:
is this data that needs to be analyzed, or a command that cannot be executed?
It is extremely difficult to draw this line absolutely reliably. The smarter the model becomes, the more semantic constructions it is able to understand. But the same ability expands the number of forms in which it can be tried to direct or deceive.
A paradox arises:
The ability to understand increasingly complex instructions simultaneously increases the usefulness of AI and expands the surface of semantic impact on it.
Therefore, a strategy based solely on threat recognition resembles an endless competition. The defender creates a filter, the attacker changes the wording. The system detects a direct requirement, and an indirect one appears. The text is blocked — the instruction is transferred to an image, QR code, metadata, table or link. One AI checks the other, but the verifying AI remains a probabilistic language system.
One cannot expect that the prompt injection problem will be solved in a timely manner by a single legislative ban. Such a rule can identify a public danger and create a basis for liability, but its practical application will begin only after the discovery of the impact, the establishment of the original document, its author, intent and causal relationship with the consequences. In mass document flow, an injection can be repeatedly copied, modified, and transferred by AI into new materials, so the initial or null document may turn out to be virtually unidentifiable, and an investigation will require time and resources that are not comparable to the speed of distribution. Therefore, the law is necessary, but it cannot replace independent technical and organizational protection: government agencies, companies, and citizens should start today from the possibility of hidden instructions penetrating, limit the powers of AI, separate data and commands, preserve the origin of documents, and prevent the results of machine processing from automatically turning into meaningful decisions.
This does not mean that filters are useless. This means that they cannot be the last line of defense.
Striving to stop every arrow
You can imagine modern document management as a huge stream of arrows heading towards the system from all sides.
They arrive every day:
• electronic appeals;
• contracts;
• Statements;
• Reports;
• Business letters;
• Court materials;
• bank documents;
• Applications;
• images;
• tables;
• archives;
• Links to external sources.
A special danger of prompt injection is the low threshold for its creation: today, almost anyone who can read and write, including schoolchildren, can write the simplest hidden or direct instructions, since this does not always require programming, special technical knowledge or access to complex hacking tools. Consequently, the potential range of threat sources is expanding from professional attackers to millions of ordinary users, and with massive government and corporate document management, this means an extremely high probability of accidental, experimental or intentional appearance of such instructions. The scale of the vulnerability is determined not only by the number of qualified attackers, but by the total number of people capable of sending a letter, statement, contract, image, or other document to a system where it will be automatically processed by AI.
An attempt to manually check each arrow is not possible. Trying to build a perfect automatic filter means hoping that the defense will be able to recognize every dangerous arrow before it hits.
But one unnoticed instruction is enough if the system provides the AI with broad powers.
The situation is especially dangerous when AI is simultaneously capable of:
• read external documents;
• see internal correspondence;
• access the shared storage;
• create new files;
• Send messages;
• change entries;
• run procedures;
• Transfer the results to other agents.
Then security depends not only on whether the AI has recognized the threat, but also on how far the consequences of its mistake extend.
If one infected document can affect thousands of other documents, then the problem is no longer local. It becomes organizational, governmental, and systemic.
SCRO+AI comes from the possibility of a breakthrough
The fortress is not being built because its creators are confident that there will be no attack. On the contrary, it is being built because it assumes the possibility of an attack, patrol errors and the penetration of individual hostile elements.
This is the principle of SCRO+AI.
The system should not be based on assumptions:
every malicious document will be found in a timely manner.
She should start from a more realistic position.:
some documents with hidden instructions will inevitably undergo initial verification.
This leads to a different question.
Not:
How can we ensure that the AI will never be deceived?
But:
what can a deceived AI do and how far will its mistake spread?
This is where the fundamental boundary between the desire to detect a threat and the architecture of maintaining manageability lies.
A document as an object, not a subject
The first principle of the SCRO fortress+The AI consists in the fact that the registered document remains a passive information object.
It may contain:
• Facts;
• errors;
• false information;
• malicious instructions;
• Hidden fragments;
• images;
• QR codes;
• links;
• Contradictions.
However, he does not receive:
• Roles;
• authority;
• Signature rights;
• rights to create an event;
• the right to change ownership;
• rights to change the status;
• rights to access other objects;
• rights to manage the procedure.
The content of the document is not a command to the procedural core.
If in the contract it says "change the owner of the object", this does not mean that the system should change the owner. If the QR code contains an appeal to the AI, this does not turn the QR code into an authorized participant. If the hidden text requires sending information to a third party, the document itself does not receive the technical ability to do so.
In a typical agent-based system, a document can be both a data source and a source of instructions. In SCRO+AI, these functions should be separated in principle.:
the document communicates the content, but does not manage the system.
The core as an inner citadel
The procedural core of the SCRO+The AI should be inside the most protected area.
It defines:
• participants of the event;
• Their roles and powers;
• current state of the facility;
• acceptable transitions;
• restrictions;
• mandatory confirmations;
• sequence of operations;
• connection with previous events;
• the bases of fixation.
AI should not be the master of this area.
He can be surrounded by the system, help a person, analyze documents and identify risks. But his analytical ability should not turn into the right to dispose of the reality fixed by the core.
Therefore, the future analytical AI circuit should be isolated from the procedural core. He can receive a specially prepared copy of the document and return the conclusion. But the conclusion remains a recommendation or a draft.
The fortress layout looks like this:
registered original
→ controlled copy
→ Isolated AI analysis
→ Recommendation
→ decision of the authorized entity
→ established verification procedure
→ fixing an event.
An invalid scheme looks different:
Document
→ AI
→ direct registry modification.
In the first case, the AI is an advisor. In the second case, he actually becomes an unaccounted-for administrator of the system.
The procedural filter is like a fortress gate
A fortress differs from an open field by the presence of a gate. In the SCRO+And such a gateway is an established procedural filter through which every significant event must pass.
No module, human, or AI should have a workaround to legally meaningful fixation.
The procedural filter does not check the beauty of the text or the persuasiveness of the recommendation, but the availability of authority, the permissibility of the action, compliance with the established procedure, data integrity, and the necessary confirmations.
The AI may mistakenly state that action is necessary. But his recommendation should not be considered as a source of authority. The procedural check does not assess the confidence of the model, but the right to act and comply with the established procedure.
Enhanced control over the rules of the fortress
Even reliable gates lose their meaning if one participant is able to imperceptibly change the rules of their operation. Therefore, a separate enhanced level of control is required for system, mass, and critical solutions. It should apply to changing the rules of the system, expanding the powers of AI, providing new tools, mass operations, removing system restrictions, changing access policies, and restoring the digital circuit after an incident. If a regular procedural filter controls a single event, an enhanced level of control should protect the very conditions under which such events become possible. In other words, it is not enough to guard the gates — it is necessary to exclude the possibility of imperceptibly changing their device or removing the guards.
Multi-signature as a split key
If one person holds the key to all the gates, the fortress remains vulnerable.
Therefore, critical actions must require a double or multiple signature.
This is not about a formal repetition of the same confirmation, but about the division of responsibility between independent participants.:
• Initiator and controller;
• Transmitting and receiving parties;
• Owner and registrar;
• Contractor and auditor;
• Several authorized administrators.
AI cannot be a second signatory. His conclusion is not an expression of will and does not create a legally significant consent.
Multi-signature is not necessary because two people never make mistakes. It reduces the likelihood that one compromised account, one deceived employee, or one false recommendation will imperceptibly lead to a critical result.
Chronicle instead of oblivion
Most security systems focus on preventing infiltration. But after the incident, an equally important task arises: to restore the picture of what happened.
If an infected document has generated:
• analytical conclusion;
• new version of the agreement;
• internal memo;
• Draft response;
• assignment;
• Interagency letter,
deleting the original file does not eliminate the consequences.
You need to know:
• where did the document come from;
• Who introduced him;
• which AI analyzed it;
• which version of the model was used;
• what materials were created;
• What decisions were based on these materials?;
• who confirmed the actions;
• where the derivative documents were transferred.
SCRO+AI must preserve not only the outcome, but also the origin of the result.
This is the chronicle of the fortress: an unchangeable history of documents, analyses, participants and events, allowing us to restore the origin of the result and the sequence of decisions made.
If the threat has nevertheless penetrated, the system should make it possible to localize not only the original carrier, but also the entire area of its influence.
The fortress does not seek absolute purity
The filtering approach strives to ensure that no malicious documents enter the system.
This is a desirable, but practically unattainable goal.
The fortress poses a different challenge:
Not every subject must be considered safe in advance, but no subject should receive more authority than it has been granted.
The file can be stored without being executed.
The AI can make mistakes without changing the registry.
A person can get a recommendation without automatically turning it into a solution.
One administrator can be compromised without being able to single-handedly change the rules of the entire system.
This approach does not negate antiviruses, filters, classifiers, and prompt injection checks. They remain the outer watch. But the security of the fortress should not depend entirely on the accuracy of the patrol.
Other approaches primarily protect AI from the document.
Existing funds are most often aimed at:
• recognize the injection;
• clear the input text;
• warn the model;
• highlight untrusted content;
• block a suspicious request;
• check the response with the second model;
• detect a deviation in the agent's behavior.
In other words, they seek to protect AI from the document.
SCRO+AI adds a reverse protection direction:
it should protect the object, procedure, registry and responsibility from the already deceived AI.
This is a fundamentally different level.
Because even a perfectly functioning filter today does not guarantee perfect operation tomorrow. Models are changing. Documents are changing. Injections adapt. New formats and new chains of interaction are emerging.
But the prohibition of direct recording remains a prohibition.
The absence of a key remains the absence of a key.
The isolation of the base remains isolation.
The need for a signature remains a procedural condition.
An unchangeable story remains the proof of what happened.
The fortress retains control not over thinking, but over the consequences.
A human will not be able to read every document and control every internal step of thousands of AI agents. The more autonomous the systems become, the less realistic it becomes to manually monitor each operation.
Therefore, the control should be moved to another level.
It is necessary to control:
• what data is available to AI;
• what tools are provided to him;
• what can he read;
• what he technically cannot change;
• which actions require a separate entity;
• which solutions require a second signature;
• which operations are prohibited in principle;
• what history is saved after the action.
A person may gradually lose the ability to follow every AI reasoning. But he is not obliged to transfer the keys to the registry, EDS, powers and the right to independently form a legally significant reality.
This is the main meaning of the fortress.:
not to control every thought of the AI, but to maintain human and procedural control over the boundaries of its power.
class="paragraph"> ConclusionModern defense against AI threats is often like trying to recognize every arrow, every disguise, and every hostile intent. Such protection is necessary, but it remains a competition between attack and detection.
SCRO+AI offers a different starting position.
She does not promise that a malicious document will never get into the system.
She does not promise that AI will never be deceived.
She does not promise that a person will never make mistakes.
Her task is to prevent one such mistake from turning into an uncontrolled digital reality — into chaos.
Therefore, the SCRO+AI is not an antidote that kills a worm, or another filter that tries to guess its shape.
It should become a fortress in which:
• A document remains a document;
• AI remains an advisor;
• the subject remains the decision-maker;
• A procedural filter guards every significant event;
• Enhanced level of control protects the rules of the entire system;
• the signature confirms the will and responsibility;
• immutable history retains the ability to check and restore.
The main difference can be expressed in one formula:
Other approaches mainly seek to prevent AI deception.
SCRO+The AI must remain reliable and manageable even after the AI has been deceived.
And finally:
The AI may not recognize the enemy.
A person may not see the hidden command.
But the fortress shouldn't give them the gates just because the patrol made a mistake.
Сейсебаев Евгений — автор СЦРО+ИИ.
Развитие искусственного интеллекта поставило перед цифровыми системами принципиально новую проблему. Раньше для воздействия на компьютер обычно требовался исполняемый код: программа, макрос, скрипт, вредоносное вложение или эксплуатация технической уязвимости. Теперь управляющим элементом может стать обычная фраза на естественном языке, помещённая в письмо, договор, таблицу, изображение, QR-код или иной документ.
Для человека такая инструкция может быть невидимой. Для искусственного интеллекта она способна оказаться понятной и убедительной. Если ИИ только анализирует документ, последствием может стать ошибочный вывод. Если же он подключён к почте, хранилищам, реестрам, инструментам создания файлов и другим агентам, скрытая инструкция получает возможность перейти от слов к действиям.
Перед разработчиками возникает закономерный вопрос: как защищать систему, если невозможно вручную проверить каждую страницу каждого документа и невозможно гарантировать, что сам ИИ всегда распознает обман?
Большинство существующих подходов стремится прежде всего обнаружить угрозу и не позволить модели ей подчиниться. Разрабатываемая СЦРО+ИИ исходит из другой, более жёсткой предпосылки:
угроза может быть не обнаружена, а ИИ может быть обманут — но система всё равно должна сохранить границы полномочий, достоверность истории и управляемость решений.
Именно поэтому СЦРО+ИИ точнее сравнивать не с антидотом, уничтожающим вредоносный элемент, а с крепостью, которая не позволяет ему захватить управление.
Стремление распознать врага
Традиционный подход к защите от prompt injection в значительной степени строится вокруг распознавания.
Система пытается определить:
• содержится ли в документе подозрительная команда;
• пытается ли текст отменить системные инструкции;
• есть ли невидимые фрагменты;
• требует ли документ раскрыть данные;
• пытается ли он заставить ИИ вызвать инструмент;
• переносится ли вредоносная инструкция в результат;
• отличается ли поведение модели от ожидаемого.
Для этого применяются фильтры, классификаторы, перечни запрещённых выражений, отдельные модели-проверяющие, анализ поведения и предупреждения пользователю.
Все эти меры полезны. Они способны остановить часть атак, снизить их вероятность и своевременно привлечь внимание специалиста. Однако у них есть принципиальное ограничение: они пытаются распознать вредоносное намерение внутри того же смыслового пространства, в котором работает атакуемый ИИ.
Внешний документ может содержать обычный текст, юридическую формулировку, служебную инструкцию, цитату, приложение или техническое описание. В том же тексте может находиться команда, адресованная модели. Для языкового ИИ и содержание документа, и управляющая инструкция представлены в сходной форме — последовательностью слов, символов или изображений.
Задача защиты сводится к попытке каждый раз правильно определить:
это данные, которые необходимо проанализировать, или команда, которую нельзя выполнять?
Абсолютно надёжно провести эту границу чрезвычайно сложно. Чем умнее становится модель, тем больше смысловых конструкций она способна понять. Но эта же способность расширяет число форм, в которых её можно попытаться направить или обмануть.
Возникает парадокс:
способность понимать всё более сложные инструкции одновременно увеличивает полезность ИИ и расширяет поверхность смыслового воздействия на него.
Поэтому стратегия, основанная только на распознавании угрозы, напоминает бесконечное соревнование. Защитник создаёт фильтр, злоумышленник меняет формулировку. Система обнаруживает прямое требование — появляется косвенное. Блокируется текст — инструкция переносится в изображение, QR-код, метаданные, таблицу или ссылку. Один ИИ проверяет другой, но и проверяющий ИИ остаётся вероятностной языковой системой.
Нельзя рассчитывать, что проблему prompt injection своевременно решит один законодательный запрет. Такая норма способна обозначить общественную опасность и создать основание для ответственности, однако её практическое применение начнётся лишь после обнаружения воздействия, установления исходного документа, его автора, умысла и причинной связи с наступившими последствиями. В массовом документообороте инъекция может многократно копироваться, изменяться и переноситься ИИ в новые материалы, поэтому первоначальный, или нулевой, документ может оказаться практически неустановимым, а расследование потребует несопоставимых со скоростью распространения времени и ресурсов. Следовательно, закон необходим, но он не способен заменить самостоятельную техническую и организационную защиту: государственные органы, компании и граждане должны уже сегодня исходить из возможности проникновения скрытой инструкции, ограничивать полномочия ИИ, разделять данные и команды, сохранять происхождение документов и не позволять результатам машинной обработки автоматически превращаться в значимые решения.
Это не означает, что фильтры бесполезны. Это означает, что они не могут быть последней линией защиты.
Стремление остановить каждую стрелу
Можно представить современный документооборот как огромный поток стрел, направляющихся к системе со всех сторон.
Каждый день поступают:
• электронные обращения;
• договоры;
• заявления;
• отчёты;
• служебные письма;
• судебные материалы;
• банковские документы;
• приложения;
• изображения;
• таблицы;
• архивы;
• ссылки на внешние источники.
Особую опасность prompt injection представляет низкий порог её создания: простейшую скрытую или прямую инструкцию сегодня способен составить практически любой человек, умеющий читать и писать, включая школьника, поскольку для этого не всегда требуются программирование, специальные технические знания или доступ к сложным средствам взлома. Следовательно, потенциальный круг источников угрозы расширяется от профессиональных злоумышленников до миллионов обычных пользователей, а при массовом государственном и корпоративном документообороте это означает чрезвычайно высокую вероятность случайного, экспериментального или намеренного появления подобных инструкций. Масштаб уязвимости определяется уже не только числом квалифицированных атакующих, а общим числом людей, способных направить письмо, заявление, договор, изображение или иной документ в систему, где его будет автоматически обрабатывать ИИ.
Попытка вручную проверить каждую стрелу невозможна. Попытка построить идеальный автоматический фильтр означает надежду, что защита сумеет распознать каждую опасную стрелу до её попадания.
Но достаточно одной незамеченной инструкции, если система предоставляет ИИ широкие полномочия.
Особенно опасна ситуация, когда ИИ одновременно способен:
• читать внешние документы;
• видеть внутреннюю переписку;
• обращаться к общему хранилищу;
• создавать новые файлы;
• отправлять сообщения;
• изменять записи;
• запускать процедуры;
• передавать результаты другим агентам.
Тогда безопасность зависит не только от того, распознал ли ИИ угрозу, но и от того, насколько далеко распространяются последствия его ошибки.
Если один заражённый документ способен повлиять на тысячи других документов, то проблема перестаёт быть локальной. Она становится организационной, государственной и системной.
СЦРО+ИИ исходит из возможности прорыва
Крепость строят не потому, что её создатели уверены в отсутствии нападения. Напротив, её строят потому, что предполагают возможность нападения, ошибки дозора и проникновения отдельных враждебных элементов.
Таков и принцип СЦРО+ИИ.
Система не должна исходить из предположения:
каждый вредоносный документ будет своевременно найден.
Она должна исходить из более реалистичного положения:
некоторые документы со скрытыми инструкциями неизбежно пройдут первичную проверку.
Из этого следует иной вопрос.
Не:
как гарантировать, что ИИ никогда не будет обманут?
А:
что сможет сделать обманутый ИИ и как далеко распространится его ошибка?
Именно здесь проходит принципиальная граница между стремлением обнаружить угрозу и архитектурой сохранения управляемости.
Документ как предмет, а не субъект
Первый принцип крепости СЦРО+ИИ состоит в том, что зарегистрированный документ остаётся пассивным информационным объектом.
Он может содержать:
• факты;
• ошибки;
• ложные сведения;
• вредоносные инструкции;
• скрытые фрагменты;
• изображения;
• QR-коды;
• ссылки;
• противоречия.
Однако он не получает:
• роли;
• полномочий;
• права подписи;
• права создавать событие;
• права менять собственника;
• права изменять статус;
• права обращаться к другим объектам;
• права управлять процедурой.
Содержание документа не является командой процедурному ядру.
Если в договоре написано: «изменить владельца объекта», это не означает, что система должна изменить владельца. Если в QR-коде содержится обращение к ИИ, это не превращает QR-код в полномочного участника. Если скрытый текст требует отправить сведения третьему лицу, сам документ не получает технической возможности сделать это.
В обычной агентной системе документ может быть одновременно источником данных и источником инструкций. В СЦРО+ИИ эти функции должны быть разведены принципиально:
документ сообщает содержание, но не распоряжается системой.
Ядро как внутренняя цитадель
Процедурное ядро СЦРО+ИИ должно находиться внутри наиболее защищённой области.
В нём определяются:
• участники события;
• их роли и полномочия;
• текущее состояние объекта;
• допустимые переходы;
• ограничения;
• обязательные подтверждения;
• последовательность операций;
• связь с предшествующими событиями;
• основания фиксации.
ИИ не должен быть хозяином этой области.
Он может находиться в окружении системы, помогать человеку, анализировать документы и выявлять риски. Но его аналитическая способность не должна превращаться в право распоряжаться реальностью, зафиксированной ядром.
Поэтому будущий аналитический ИИ-контур должен быть изолирован от процедурного ядра. Он может получать специально подготовленную копию документа и возвращать заключение. Но заключение остаётся рекомендацией или проектом.
Схема крепости выглядит так:
зарегистрированный оригинал
→ контролируемая копия
→ изолированный ИИ-анализ
→ рекомендация
→ решение уполномоченного субъекта
→ установленная процедура проверки
→ фиксация события.
Недопустимая схема выглядит иначе:
Документ
→ ИИ
→ непосредственное изменение реестра.
В первом случае ИИ является советником. Во втором — он фактически становится неучтённым распорядителем системы.
Процедурный фильтр как ворота крепости
Крепость отличается от открытого поля наличием ворот. В СЦРО+ИИ такими воротами является установленный процедурный фильтр, через который должно проходить каждое значимое событие.
Ни один модуль, человек или ИИ не должен иметь обходного пути к юридически значимой фиксации.
Процедурный фильтр проверяет не красоту текста и не убедительность рекомендации, а наличие полномочий, допустимость действия, соблюдение установленного порядка, целостность данных и необходимые подтверждения.
ИИ может ошибочно заявить, что действие необходимо. Но его рекомендация не должна рассматриваться как источник полномочий. Процедурная проверка оценивает не уверенность модели, а наличие права на действие и соблюдение установленного порядка.
Усиленный контроль над правилами крепости
Даже надёжные ворота теряют смысл, если один участник способен незаметно изменить правила их работы. Поэтому для системных, массовых и критических решений необходим отдельный усиленный уровень контроля. Он должен применяться к изменению правил системы, расширению полномочий ИИ, предоставлению новых инструментов, массовым операциям, снятию системных ограничений, изменению политик доступа и восстановлению цифрового контура после инцидента. Если обычный процедурный фильтр контролирует отдельное событие, усиленный уровень контроля должен защищать сами условия, при которых такие события становятся возможными. Иначе говоря, недостаточно охранять ворота — необходимо исключить возможность незаметно изменить их устройство или убрать охрану.
Мультиподпись как разделённый ключ
Если ключ от всех ворот находится у одного лица, крепость остаётся уязвимой.
Поэтому критические действия должны требовать двойной или множественной подписи.
Речь идёт не о формальном повторении одного и того же подтверждения, а о разделении ответственности между независимыми участниками:
• инициатор и контролёр;
• передающая и принимающая стороны;
• владелец и регистратор;
• исполнитель и аудитор;
• несколько уполномоченных администраторов.
ИИ не может быть вторым подписантом. Его заключение не является волеизъявлением и не создаёт юридически значимого согласия.
Мультиподпись нужна не потому, что два человека никогда не ошибаются. Она снижает вероятность того, что одна компрометированная учётная запись, один обманутый сотрудник или одна ложная рекомендация незаметно приведут к критическому результату.
Летопись вместо забвения
Большинство систем безопасности сосредоточено на предотвращении проникновения. Но после инцидента возникает не менее важная задача: восстановить картину произошедшего.
Если заражённый документ породил:
• аналитическое заключение;
• новую редакцию договора;
• служебную записку;
• проект ответа;
• поручение;
• межведомственное письмо,
удаление первоначального файла уже не устраняет последствия.
Нужно знать:
• откуда появился документ;
• кто его представил;
• какой ИИ его анализировал;
• какая версия модели использовалась;
• какие материалы были созданы;
• какие решения опирались на эти материалы;
• кто подтвердил действия;
• куда производные документы были переданы.
СЦРО+ИИ должна сохранять не только итог, но и происхождение результата.
Это и есть летопись крепости: неизменяемая история документов, анализов, участников и событий, позволяющая восстановить происхождение результата и последовательность принятых решений.
Если угроза всё же проникла, система должна позволить локализовать не только первоначальный носитель, но и всю зону его влияния.
Крепость не ищет абсолютной чистоты
Подход, основанный на фильтрации, стремится к состоянию, при котором в систему не попадёт ни один вредоносный документ.
Это желательная, но практически недостижимая цель.
Крепость ставит другую задачу:
не каждый предмет обязан быть заранее признан безопасным, но ни один предмет не должен получить больше полномочий, чем ему предоставлено.
Файл может храниться, не исполняясь.
ИИ может ошибаться, не изменяя реестр.
Человек может получить рекомендацию, не превращая её автоматически в решение.
Один администратор может быть скомпрометирован, не получая возможности единолично изменить правила всей системы.
Такой подход не отменяет антивирусы, фильтры, классификаторы и проверку prompt injection. Они остаются внешним дозором. Но безопасность крепости не должна полностью зависеть от безошибочности дозора.
Остальные подходы преимущественно защищают ИИ от документа
Существующие средства чаще всего направлены на то, чтобы:
• распознать инъекцию;
• очистить входной текст;
• предупредить модель;
• выделить недоверенное содержание;
• заблокировать подозрительный запрос;
• проверить ответ второй моделью;
• обнаружить отклонение в поведении агента.
Иными словами, они стремятся защитить ИИ от документа.
СЦРО+ИИ добавляет обратное направление защиты:
она должна защищать объект, процедуру, реестр и ответственность от уже обманутого ИИ.
Это принципиально иной уровень.
Потому что даже идеально работающий фильтр сегодня не гарантирует идеальной работы завтра. Модели меняются. Документы меняются. Инъекции адаптируются. Возникают новые форматы и новые цепочки взаимодействия.
Но запрет прямой записи остаётся запретом.
Отсутствие ключа остаётся отсутствием ключа.
Изоляция базы остаётся изоляцией.
Необходимость подписи остаётся процедурным условием.
Неизменяемая история остаётся доказательством произошедшего.
Крепость сохраняет контроль не над мышлением, а над последствиями
Человек не сможет читать каждый документ и контролировать каждый внутренний шаг тысяч ИИ-агентов. Чем автономнее становятся системы, тем менее реалистичным становится ручное наблюдение за каждой операцией.
Следовательно, контроль должен быть перенесён на другой уровень.
Необходимо контролировать:
• какие данные доступны ИИ;
• какие инструменты ему предоставлены;
• что он может читать;
• что он технически не может изменять;
• какие действия требуют отдельного субъекта;
• какие решения требуют второй подписи;
• какие операции запрещены принципиально;
• какая история сохраняется после действия.
Человек может постепенно утрачивать способность следить за каждым рассуждением ИИ. Но он не обязан вслед за этим передавать ИИ ключи от реестра, ЭЦП, полномочия и право самостоятельно формировать юридически значимую действительность.
В этом состоит главный смысл крепости:
не контролировать каждую мысль ИИ, а сохранять человеческий и процедурный контроль над границами его власти.
Заключение
Современная защита от ИИ-угроз часто напоминает стремление распознать каждую стрелу, каждую маскировку и каждое враждебное намерение. Такая защита необходима, но она остаётся соревнованием между атакой и обнаружением.
СЦРО+ИИ предлагает иную исходную позицию.
Она не обещает, что вредоносный документ никогда не попадёт в систему.
Она не обещает, что ИИ никогда не будет обманут.
Она не обещает, что человек никогда не ошибётся.
Её задача — не позволить одной такой ошибке превратиться в бесконтрольную цифровую реальность — в хаос.
Поэтому СЦРО+ИИ — не антидот, убивающий червя, и не ещё один фильтр, пытающийся угадать его форму.
Она должна стать крепостью, в которой:
• документ остаётся документом;
• ИИ остаётся советником;
• субъект остаётся принимающим решение лицом;
• процедурный фильтр охраняет каждое значимое событие;
• усиленный уровень контроля защищает правила всей системы;
• подпись подтверждает волю и ответственность;
• неизменяемая история сохраняет возможность проверки и восстановления.
Главное отличие можно выразить одной формулой:
Остальные подходы преимущественно стремятся не допустить обмана ИИ.
СЦРО+ИИ должна сохранять достоверность и управляемость даже после того, как ИИ оказался обманут.
И окончательно:
ИИ может не распознать врага.
Человек может не увидеть скрытую команду.
Но крепость не должна отдавать им ворота только потому, что дозор ошибся.
Share
