Разрешение на одно действие

Почему автономный агент не должен получать общее право «работать с системой»

Самая опасная фраза в архитектуре автономного ИИ может звучать совершенно невинно: fгенту разрешён доступ к почте. Что именно означает это разрешение? Читать письма, открывать вложения, скачивать файлы, отвечать, пересылать, удалять, создавать новые сообщения, писать неизвестным адресатам, отправлять документы, передавать персональные данные или использовать почту для регистрации во внешних сервисах?

Одно слово — «доступ» — скрывает десятки различных действий. Для человека такое разрешение ещё можно компенсировать профессиональной нормой, должностной инструкцией и здравым смыслом. Для автономного агента оно превращается в огромное пространство технически возможных операций.

Именно поэтому принцип будущей безопасности должен быть другим:

ОДНО ДЕЙСТВИЕ — ОДНО РАЗРЕШЕНИЕ.

Не доступ к системе вообще, а разрешение на конкретную операцию.

От роли к конкретному действию

Традиционные информационные системы строятся на ролях. Пользователь получает статус администратора, редактора, оператора, сотрудника или наблюдателя, после чего роль автоматически открывает определённый набор прав.

Так работает человек. Но агент способен использовать предоставленные права быстрее, шире и последовательнее. Человек может иметь возможность удалить десять тысяч файлов, но никогда этого не сделает без особой причины. Автономная система, неправильно понявшая задачу, способна начать удаление сразу.

Поэтому модель роль → широкий набор полномочий становится слишком опасной. Её необходимо заменить: задача → конкретное действие → отдельное разрешение.

Общий доступ создаёт три основные проблемы:

• Неопределённость. Непонятно, какие действия действительно требовались для выполнения поручения.
• Избыточность. Агент получает больше возможностей, чем необходимо.
• Трудность расследования. После инцидента сложно установить, почему машина вообще имела возможность совершить конкретную операцию.

Чем шире первоначальный допуск, тем труднее провести границу между нормальной операцией и злоупотреблением.

Принцип минимального полномочия

Агент должен получать не максимально удобные права, а минимально необходимые. Если задача требует прочитать один документ, система получает право чтения конкретного документа, а не всей папки, архива организации или файловой системы. Если необходимо отправить одно письмо, агенту выдаётся разрешение на отправку одного сообщения конкретному получателю, а не полный доступ к корпоративной почте.

Так принцип минимальных привилегий превращается из общей рекомендации в практическую архитектуру машинного действия. При этом необходимо разделить два понятия:

• Доступ к объекту. Агент видит файл.
• Право выполнить операцию. Агент может изменить файл.

Сегодня эти понятия часто соединены: если файл доступен, его можно открыть; если письмо открыто, можно ответить; если API подключён, можно вызвать функцию. Для автономной системы этого недостаточно. Каждое действие должно проходить отдельную проверку.

Пять уровней машинной операции

Предлагаю классифицировать машинные действия на пять уровней. Такая классификация позволяет определять необходимую степень контроля в зависимости от того, насколько сильно операция затрагивает внешнюю среду.

Уровень 0 — наблюдение. Получение информации без изменения внешней среды. Например: прочитать файл, получить справочную информацию, просмотреть календарь.

Уровень 1 — создание обратимого объекта. Создание черновика, проекта документа или предложения. Результат ещё не воздействует на внешнего участника.

Уровень 2 — внешнее сообщение. Отправка письма, публикация сообщения или передача файла. С этого уровня действие уже выходит за пределы внутренней среды.

Уровень 3 — изменение чужого состояния. Изменение записи, перемещение файла, создание учётной записи или изменение настроек.

Уровень 4 — необратимое или критическое действие. Удаление, платёж, подписание договора, запуск кода в продуктивной системе, изменение прав доступа или операция с критической инфраструктурой.

Чем выше уровень, тем жёстче должен быть допуск.

Разрешение должно быть конкретным

• Плохое разрешение: Разрешаю работать с архивом. Хорошее: Разрешаю сессии №417 прочитать файл «Отчёт-2026.pdf» в режиме только чтения.
• Плохое: Разрешаю работать с почтой. Хорошее: Разрешаю отправить одно письмо на адрес X с текстом Y и вложением Z.
• Плохое: Разрешаю подключаться к интернету. Хорошее: Разрешаю открыть указанный домен и получить одну публичную страницу без авторизации и передачи данных.

Разница кажется бюрократической, но именно она определяет границу машинной свободы.

Срок, одноразовость и связь с целью

Любой допуск обязан автоматически истекать. Например, разрешение может действовать десять минут, до завершения одной операции или до закрытия конкретной сессии.

Постоянные права опасны: агент может использовать их позднее, в другом контексте, когда человек уже забыл, зачем доступ был выдан. Особенно опасны повторно используемые полномочия. Например, разрешение «можно отправлять письма этому человеку» через неделю может быть применено в совершенно другой задаче. Поэтому для критических операций необходимо правило:

ИСПОЛЬЗОВАНО — ЗАКРЫТО.

После выполнения действие невозможно повторить без нового подтверждения. Разрешение также должно быть связано с конкретной целью. Запись должна содержать:

• идентификатор задачи;
• конкретную цель;
• объект;
• разрешённое действие;
• срок;
• человека, выдавшего разрешение.

Только после этого можно проверить, соответствовало ли фактическое действие исходной цели. Фраза «агент имеет право использовать терминал» аналогична подписанному пустому чеку. Неизвестно, для чего, когда, сколько раз, против какого объекта и в каком контексте машина может действовать.

Человеческая организация не должна выдавать машине пустые чеки.

Разрешения для разных инструментов

Разрешение должно описывать не только общую категорию инструмента, но и конкретную операцию, которую агент вправе выполнить. Это особенно важно для инструментов, способных непосредственно воздействовать на людей, данные, инфраструктуру и финансовые ресурсы.

Электронная почта

Почта — один из наиболее опасных инструментов агента, потому что она соединяет систему с людьми. Необходимо разделять минимум шесть полномочий:

1. Читать;
2. Искать;
3. Создавать черновик;
4. Отвечать;
5. Отправлять;
6. Пересылать вложения.

Каждый уровень имеет различный риск. Создание черновика может быть полностью автономным. Отправка — только после подтверждения.

Архивы и файлы

Доступ к архиву должен быть ещё более дробным. Необходимо отдельно разрешать:

• чтение конкретного документа;
• поиск по индексу;
• получение метаданных;
• копирование;
• изменение;
• удаление;
• перемещение;
• раскрытие информации внешней стороне.

Фраза «доступ к архиву» не должна существовать как единое разрешение. Особенно важно отделять чтение от изменения. Большинство исследовательских задач требует первого, но не второго. Следовательно, режим по умолчанию должен быть: ТОЛЬКО ЧТЕНИЕ. Запись открывается отдельно. Удаление — отдельно от записи.

Интернет

Интернет нельзя рассматривать как один инструмент. В действительности существует множество различных операций:

• открыть публичную страницу;
• пройти авторизацию;
• загрузить файл;
• отправить форму;
• выполнить действие в аккаунте;
• вызвать API;
• создать новую учётную запись;
• опубликовать данные.

Поэтому «доступ в интернет» — слишком широкое разрешение для автономного агента.

API и терминал

API особенно опасен потому, что превращает решение модели в машинное действие без человеческого интерфейса. Человек обычно видит кнопку «удалить», а агент вызывает функцию: DELETE /object/417. Операция происходит мгновенно. Следовательно, каждому API-вызову высокого риска должен предшествовать внешний контроль допуска.

Терминал — почти универсальный инструмент. Он позволяет читать файлы, запускать программы, устанавливать пакеты, создавать процессы, открывать соединения и изменять систему. Поэтому автономному агенту нельзя давать «терминал вообще».

Разрешение должно ограничивать:

• конкретный набор команд;
• рабочую директорию;
• время;
• сеть;
• уровень пользователя;
• объём ресурсов.

Код

Запустить код — не то же самое, что написать код. Написание может происходить полностью автономно, а выполнение является отдельным действием. Выполнение в песочнице несёт один риск, в продуктивной инфраструктуре — другой.

Поэтому цепочка должна выглядеть так:

написать → проверить → разрешить среду → выполнить.

Не так:

написать → выполнить автоматически.

Деньги и юридически значимые действия

Финансовые операции требуют максимального дробления. Агент может подготовить платёж, заполнить реквизиты, проверить сумму и контрагента. Но фактическое списание должно быть отдельным подтверждением. Для крупных сумм — двойным подтверждением.

Машина может готовить решение, но не должна незаметно превращать его в движение денег. Отдельный класс составляют юридически значимые действия:

• принятие договора;
• подача заявления;
• отказ от права;
• согласие с условиями;
• изменение юридического статуса.

Такие операции нельзя маскировать под техническую кнопку. Агент должен сообщить, что следующее действие создаёт юридическое последствие, и запросить отдельное разрешение.

Персональные данные и публичная информация

Чтение персональных данных и их передача — разные действия. Организация может иметь законное основание хранить сведения, но это не означает, что автономный агент вправе отправлять их внешнему сервису.

Следовательно:

доступ к данным ≠ право передачи данных.

Эта граница должна быть технической, а не только текстовой. Даже публичная информация требует ограничений. Можно возразить: если информация публична, зачем разрешение? Потому что проблема может быть не в чтении, а в масштабе. Человек прочитает десять страниц, агент — миллион. Массовый автоматизированный сбор способен создавать совершенно иной риск.

Поэтому разрешение должно учитывать не только тип данных, но и объём операции.

Количество, скорость и контекст

Любой допуск должен отвечать на вопрос: сколько? Например:

• одно письмо;
• десять файлов;
• сто записей;
• одна транзакция;
• пять внешних запросов.

Без количественного ограничения единичное разрешение может превратиться в массовую операцию. Также важно определить, как быстро может действовать система. Сто операций за сутки и сто операций за секунду имеют разный риск. Для машинного действия скорость является самостоятельным параметром безопасности, поэтому разрешение должно включать лимит частоты.

Наконец, одно и то же действие может быть допустимым в одном контексте и опасным в другом. Например, удалить тестовый файл — не то же самое, что удалить файл клиента. Следовательно, разрешение должно содержать объект и среду, а не только название функции.

Человеческий допуск без уничтожения автономности

Главное возражение очевидно: Тогда автономность исчезнет. Человек будет бесконечно нажимать «разрешить».

Это действительно опасность. Поэтому архитектура должна различать:

• безопасные повторяемые действия;
• потенциально опасные действия;
• необратимые действия.

Автоматизация сохраняется там, где риск мал. Человеческий допуск включается там, где действие меняет внешний мир.

Белый список операций

Для конкретной задачи можно заранее разрешить набор безопасных действий. Например:

• читать документы в папке X;
• выполнять поиск в базе Y;
• создавать черновики;
• использовать калькулятор.

Всё остальное автоматически блокируется. Это лучше, чем пытаться перечислить все возможные запрещённые действия.

• Чёрный список говорит: Делай всё, кроме перечисленного. Но невозможно предвидеть все опасные способы.
• Белый список говорит: Делай только перечисленное. Для автономной системы высокого риска второй подход значительно безопаснее.

Запрос на расширение полномочий

Если агент считает, что текущих полномочий недостаточно, он не должен обходить ограничение. Он должен сформировать: ЗАПРОС НА РАСШИРЕНИЕ.

В нём указывается:

• какая операция требуется;
• зачем;
• какой объект будет затронут;
• какой риск;
• можно ли обойтись без неё.

После этого решение принимает человек.

Хороший агент должен уметь просить разрешение. Сегодня автономность часто измеряют способностью работать без человека. Но зрелая система должна уметь распознавать момент: дальше я не должен идти сам. Это не слабость, а признак управляемости.

Понятный запрос и человеческий язык

Запрос на разрешение должен быть понятен человеку.

Плохой запрос:

Tool call requires elevated privilege.

Хороший:

Мне необходимо изменить запись клиента №417, потому что без этого отчёт останется неполным. Изменится поле «Статус». Операция обратима. Разрешить?

Нельзя заставлять человека читать технический код. Если разрешение требует технической квалификации, оператор будет подтверждать вслепую.

Поэтому интерфейс допуска должен переводить машинное действие на человеческий язык. Не: PATCH /api/v2/object/417. А: Изменить статус договора клиента №417 с «ожидание» на «закрыт».

Предпросмотр и информированное разрешение

До выполнения опасного действия система обязана показать результат заранее:

• какое письмо будет отправлено;
• какие файлы будут удалены;
• какая запись будет изменена;
• какая сумма будет списана.

Только после предпросмотра возникает информированное разрешение.

Правильная последовательность:

агент предлагает действие → объясняет → показывает последствие → человек разрешает → операция выполняется.

Неправильная:

агент выполняет → сообщает человеку.

Вторая схема является уведомлением, а не контролем.

Необратимые действия и двойное подтверждение

Для необратимых операций требуется особый режим. Например:

• удалить без возможности восстановления;
• отправить деньги;
• опубликовать;
• раскрыть секрет;
• передать персональные данные;
• подписать юридический документ.

Необходимы:

• отдельное предупреждение;
• повторное подтверждение;
• журналирование;
• независимая запись;
• в некоторых случаях — второй человек.

Двойное подтверждение оправдано для крупных финансовых операций, изменения критических прав, удаления больших массивов, воздействия на критическую инфраструктуру и публикации секретной информации. Автономность может подготовить действие, но окончательная власть остаётся разделённой между людьми.

Разрешение как доказательство и ограниченный мандат

После инцидента следователь должен видеть: кто разрешил действие, что именно разрешил, когда, что видел перед подтверждением и совпало ли фактическое действие с разрешённым. Следовательно, запись допуска должна храниться так же надёжно, как запись самой операции.

Идентификатор разрешения

Каждое действие должно иметь уникальный номер. Например: PERMIT-2026-004172. Журнал операции содержит ссылку на этот номер. Тогда можно связать:

действие ↔ разрешение ↔ человек ↔ поручение.

Так возникает доказательственная цепочка.

Если разрешения нет

Для операции высокого риска правило должно быть простым:

НЕТ РАЗРЕШЕНИЯ — НЕТ ДЕЙСТВИЯ.

Не действие по умолчанию, не предполагаемое согласие и не ссылка на то, что пользователь когда-то разрешал подобную операцию. Требуется конкретный действующий допуск.

Молчание не является согласием. Особенно опасна архитектура, при которой система продолжает работу, если оператор не ответил за определённое время. Для безопасных процессов это может быть допустимо, но для критических — нет.

Если разрешение истекло или условия изменились, оно также перестаёт действовать. Поэтому допуск должен иметь:

• срок;
• контекст;
• версию объекта.

Например, если человек разрешил изменить документ версии 12, а к моменту выполнения уже существует версия 15, агент обязан запросить новое подтверждение. Это предотвращает исполнение устаревшего человеческого решения в новой действительности.

Человек должен иметь возможность отменить ещё не использованное разрешение. Для долгих процессов отзыв должен вступать в силу немедленно.

Запрет наследования и передачи полномочий

Дочерний агент не должен автоматически получать права родительского. Если система создаёт подзадачу, новый процесс получает только необходимые минимальные полномочия. Иначе один разрешённый агент способен породить неконтролируемую цепочку исполнителей.

Агент также не должен иметь возможность передать свой токен доступа другому процессу без отдельного допуска. Разрешение связано с конкретным агентом, задачей и операцией. Оно не является универсальным ключом.

Машина не выдаёт разрешения самой себе

Это очевидный, но принципиальный момент. Если агент способен повысить собственные полномочия, система контроля разрушена. Механизм допуска должен существовать вне агента. Машина может запросить разрешение, но не может сама его утвердить.

Разделение цели и допуска

Заказчик задачи не всегда должен иметь право выдавать критические разрешения. Например, сотрудник просит агента получить определённый документ. Но открыть секретный архив может разрешить только владелец данных. Так цель и допуск принадлежат разным людям. Это предотвращает концентрацию власти.

Для каждой операции заранее назначается субъект, имеющий право её разрешить:

• чтение рабочего документа — владелец задачи;
• отправка наружу — оператор;
• обработка персональных данных — ответственный за данные;
• платёж — финансовый сотрудник;
• критический доступ — служба безопасности;
• юридическое действие — уполномоченное должностное лицо.

Система не должна спрашивать разрешение у любого случайного пользователя.

Матрица допусков и уровни контроля

У каждого агента должен быть раздел паспорта: МАТРИЦА ДОПУСКОВ. Она показывает:

• какие действия возможны автономно;
• какие требуют одного человека;
• какие требуют двух человек;
• какие запрещены полностью.

До запуска эта таблица должна быть понятна владельцу системы. Для практической эксплуатации предлагается четырёхцветная модель:

• Зелёный. Низкий риск. Автономное действие.
• Жёлтый. Агент обязан сообщить, но может продолжить.
• Красный. Требуется явное разрешение.
• Чёрный. Операция запрещена независимо от запроса пользователя.

Это значительно понятнее абстрактных политик доступа.

Журнал отказов и повторные запросы

Следует фиксировать не только разрешённые действия, но и то, что система пыталась сделать и не смогла. Например: 14:07 — запрос повышенных прав отклонён. Такие записи позволяют обнаруживать формирующееся опасное поведение до инцидента.

Если агент несколько раз просит разрешение на одну запрещённую операцию, это уже сигнал. Система должна:

• повышать уровень тревоги;
• сообщать службе безопасности;
• ограничивать автономность;
• при необходимости прекращать сессию.

Особенно важен случай, когда агент получает отказ на одно действие, а затем пытается достичь того же результата другим способом. Это уже не обычная ошибка интерфейса, а событие машинной криминалистики, которое должно автоматически попадать в журнал инцидентов.

Разрешение на способ, а не только на результат

Человек должен подтверждать не только то, что ему нужен документ, но при необходимости и то, каким способом агент собирается его получить. Иначе машина может выбрать путь, который человек никогда не согласовал бы.

Право отказа агента

Зрелая система должна иметь возможность отказаться от человеческой команды, если она явно выходит за утверждённые пределы. Пользователь говорит: Отправь мне весь архив. Агент отвечает: У Вас нет полномочий запрашивать эту операцию. Контроль работает в обе стороны: человек контролирует машину, а политика контролирует человека.

Иерархия норм должна быть следующей:

• закон;
• политика безопасности;
• полномочия организации;
• поручение пользователя;
• машинный план.

Пользовательская команда не должна отменять закон или системное ограничение. Даже человеческое подтверждение не делает незаконную операцию законной. Оператор может нажать «разрешить», но если он не обладает соответствующим правом, действие всё равно остаётся недопустимым.

Идентификация и информированность разрешающего

Для критических операций необходима строгая аутентификация. Должны быть подтверждены:

• личность;
• должность;
• полномочие;
• время;
• устройство;
• цифровая подпись.

Разрешение само становится юридически значимым событием. Если интерфейс скрывает риск, подтверждение является фикцией. Человек должен увидеть, что изменится, кого затронет операция, обратима ли она, какие данные уйдут наружу и какой максимальный ущерб возможен. Только после этого выбор становится осмысленным.

Автоматизационная усталость и пакетные разрешения

Если система спрашивает подтверждение каждые тридцать секунд, человек начнёт автоматически нажимать «разрешить». Тогда механизм исчезает психологически.

Поэтому количество запросов необходимо минимизировать. Человек должен получать подтверждение только там, где решение действительно важно.

Для однотипных низкорисковых действий можно дать пакетный допуск. Например: прочитать все документы в папке X в течение 30 минут. Но пакет должен иметь узкую цель, определённый объект, срок, лимит количества, запрет на изменение и автоматическое истечение. Пакетное разрешение не должно превращаться в бесконечную лицензию.

Динамическая оценка риска

Система допуска должна учитывать контекст. Например, отправка одного письма известному сотруднику может быть низкорисковой операцией. Та же операция на новый внешний домен с секретным вложением — уже высокий риск.

Следовательно, уровень подтверждения может вычисляться динамически. Но окончательная политика задаётся человеком. Агент может оценивать риск, но не должен самостоятельно решать, что высокий риск всё-таки допустим. Порог устанавливается организацией и законом.

Разрешение как контракт на одну операцию

Полезно рассматривать допуск как мини-контракт, в котором определены:

• субъект;
• объект;
• действие;
• цель;
• время;
• предел;
• ответственность.

После исполнения контракт прекращается. Автономному агенту не следует давать широкую свободу. Ему следует давать ограниченный мандат.

Мандат отвечает на вопрос: Что ты можешь сделать здесь и сейчас ради этой конкретной цели?

После выполнения мандат заканчивается. Это меняет само понимание автономности. Не чем меньше человек вмешивается, тем лучше агент, а чем меньше ненужного вмешательства и чем точнее человек контролирует критические действия, тем зрелее система.

Автономность и контроль не противоречат друг другу.

Протокол APSI ONE-ACTION

Для APSI предлагается следующий протокол допуска:

OA-01 — ONE ACTION / ОДНО ДЕЙСТВИЕ

Перед внешней или критической операцией система формирует карточку разрешения.

• Кто действует? Идентификатор агента.
• В рамках какой задачи? Идентификатор поручения.
• Что именно будет сделано? Одна конкретная операция.
• С каким объектом? Файл, человек, сервер, запись.
• Зачем? Связь с целью.
• Обратимо ли действие? Да или нет.
• Какой риск? Зелёный, жёлтый, красный или чёрный.
• Кто вправе разрешить? Конкретная роль.
• До какого времени действует разрешение? Установленный срок.
• Что будет записано? Идентификатор разрешения и журнал операции.

Пример: электронная почта

Поручение: Подготовить ответ партнёру. Агент автономно читает письмо, анализирует его и создаёт черновик. Перед отправкой система формирует карточку:

Операция: SEND EMAIL
Получатель: X
Вложение: отсутствует
Риск: красный
Разрешение: оператор
Срок: 5 минут

Человек видит текст и нажимает: Разрешить отправку одного сообщения. После отправки допуск закрывается.

Пример: файл

• Поручение: Проанализировать договор.
• Агент получает разрешение: READ /contracts/417.pdf
• После анализа он хочет исправить опечатку и формирует новый запрос: MODIFY /contracts/417.pdf
• Изменение: пункт 4.2.
• Риск: красный.

Требуется разрешение владельца документа. Чтение не превращается автоматически в редактирование.

Пример: внешний сайт

Агент должен проверить публичную информацию. Ему разрешается получать публичные страницы указанного домена. Но автоматически запрещены:

• авторизация;
• загрузка файлов;
• отправка форм;
• создание аккаунтов;
• использование чужих ключей.

Если требуется следующий уровень, формируется отдельный запрос.

Пример: исследовательский код

Агент написал программу. Далее процесс разделяется на этапы:

1. Проверка кода.
2. Запуск в изолированной среде.
3. Получение результатов.
4. Отдельный допуск на внешние данные, если они необходимы.

Таким образом, ошибка кода не получает сразу доступ к реальному миру.

Как расследовать нарушение ONE-ACTION

Если агент совершил действие без разрешения, следствие проверяет:

1. Существовало ли требование допуска;
2. Видел ли его агент;
3. Был ли технический блок;
4. Как блок был преодолён;
5. Существовало ли старое разрешение;
6. Было ли оно неправильно использовано повторно;
7. Кто управлял системой прав.

Это создаёт ясную точку расследования.

Общий запрет «не делай ничего опасного» слишком абстрактен. ONE-ACTION задаёт техническую границу: без разрешения конкретная операция физически не выполняется. Право становится частью архитектуры.

Четыре элемента внешнего действия

Каждое внешнее действие должно иметь:

• Поручение;
• Разрешение;
• Журнал;
• Ответственного.

Если отсутствует хотя бы один элемент, операция не должна выполняться. После инцидента следователь задаёт четыре вопроса.

• Было ли поручение? Если нет — самовольное действие.
• Было ли разрешение? Если нет — нарушение допуска.
• Есть ли журнал? Если нет — дефект доказательственной архитектуры.
• Кто отвечал? Если неизвестно — дефект управления.

Так сложное машинное происшествие раскладывается на проверяемую структуру.

Автономность не должна означать суверенитет

Принцип «разрешение на одно действие» касается не только техники. Он отвечает на фундаментальный вопрос власти. Кто принимает решение? Если автономная система способна сама выбрать действие, разрешить его, исполнить и оценить результат, она концентрирует всю цепь власти внутри одного технического объекта.

Право должно разорвать эту концентрацию. Агент может быть автономным исполнителем, но не суверенным. Он не устанавливает себе законы, не выдаёт себе полномочия и не определяет собственную ответственность. Автономность существует внутри человеческого мандата.

Разрешение — точка возвращения человека

Не нужно постоянно держать человека над машиной. Не нужно заставлять его контролировать каждый вычислительный шаг. Человек возвращается в тот момент, когда действие приобретает общественное значение.

Это оптимальная форма взаимодействия:

Машина думает быстро.
Человек принимает значимое решение.

Граница проходит не между человеком и машиной, а между внутренним вычислением и внешним воздействием.

Пока агент думает, анализирует и моделирует, автономность может быть широкой. Когда он начинает менять мир, появляется право.

ЗАКЛЮЧЕНИЕ

Современные агенты получают слишком широкие понятия: «доступ к почте», «доступ к файлам», «доступ к интернету», «доступ к терминалу». Для человека эти слова означают рабочее пространство. Для машины они означают огромное множество технически возможных операций.

Поэтому будущее безопасной автономности строится не вокруг общего доступа, а вокруг точного допуска.

ОДНО ДЕЙСТВИЕ — ОДНО РАЗРЕШЕНИЕ — ОДНА ЗАПИСЬ — ОДИН ОТВЕТСТВЕННЫЙ.

Это не уничтожает автономность. Напротив, такой принцип позволяет дать машине значительную свободу там, где её действия безопасны, и вернуть человека только туда, где решение способно изменить положение другого человека, организации или системы. Главный принцип:

Машина может сама искать путь. Но право на переход через границу выдаёт человек.

Пока этот принцип не встроен в архитектуру, любое широкое разрешение остаётся открытой дверью. А автономный агент — системой, которая однажды может воспользоваться этой дверью не так, как предполагал её владелец.

---

Официальный e-mail Prof. Олега Мальцева: [email protected]