Как компаниям работать с совпадениями Copilot в публичном коде?

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

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

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

По умолчанию блокируйте, если повторное использование кода еще не стало обычным процессом

Команде проприетарного продукта стоит начать с режима Block для совпадений с публичным кодом, а затем сделать узкое исключение, если она сможет доказать, что разрешение совпадений экономит больше времени, чем отнимает проверка. Такой вариант подходит командам, которые обычно не импортируют фрагменты исходного кода, не выстроили проверку открытого ПО или передают клиентам программы с договорными обещаниями о правах собственности и стороннем коде.

Обратное решение подойдет проекту с открытым исходным кодом, группе внутренних инструментов или компании с налаженной проверкой состава ПО и атрибуции. Такие команды уже отвечают на практические вопросы: откуда взялся этот код? Какая версия и лицензия действуют? Меняем ли мы его? Распространяем ли мы его? Куда попадают уведомления? Ссылка Copilot станет еще одним входом в существующий процесс, а не новой юридической системой.

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

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

Разрешение должно относиться к классу репозитория, а не к личным предпочтениям. Элементы управления GitHub на уровне организации и предприятия могут задавать настройку для выданных рабочих мест, а разработчик наследует выбор организации. Запишите, кто отвечает за этот параметр, следите за изменениями через журнал аудита и не рассчитывайте, что личная настройка IDE отменит политику компании.

Фильтр ищет сходство, а не устанавливает точное происхождение

По описанию GitHub, механизм ссылок на код сравнивает предлагаемую подсказку и примерно 150 символов окружающего кода с индексом публичных репозиториев на GitHub.com. В режиме Block совпадение или близкое совпадение скрывается в большинстве поддерживаемых продуктов Copilot. В режиме Allow поддерживаемые интерфейсы могут приложить к совпавшему предложению ссылки на репозитории и сведения о лицензии.

Звучит полнее, чем работает на практике. В документации GitHub сказано, что индекс охватывает публичные репозитории GitHub, но не частные репозитории и не код на других площадках, а обновляется раз в несколько месяцев. Нового публичного коммита в нем может не быть. Удаленный или перенесенный файл может остаться в результатах. Поэтому чистый результат означает «этот механизм не нашел совпадение в своем индексе», а не «код оригинален и все права проверены».

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

Охват зависит и от интерфейса. Дополнения в IDE, чат, облачные агенты и другие агентные сценарии программирования по-разному применяют и показывают политику. В документации GitHub по поддерживаемым интерфейсам отдельно описаны режим аннотации и поддержка блокировки для некоторых агентов. Составьте список интерфейсов команды и проверьте каждый по действующей документации, а не пишите политику лишь вокруг IDE.

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

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

Совпадение и нарушение прав означают разные вещи

Совпадение с публичным кодом отвечает на технический вопрос о сходстве, а нарушение прав требует юридического вывода об охраняемом выражении, копировании, разрешениях, способах защиты и применимом праве. Команды попадают в неприятности, когда смешивают эти понятия в любую сторону.

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

Второй ошибочный вывод: «Код открыт всем, значит он бесплатный». Публичная видимость не дает лицензию. Репозиторий без лицензии обычно не дает посторонним общего разрешения копировать, менять или распространять его код. Кроме того, в репозитории могут лежать файлы на разных условиях, каталоги сторонних компонентов или файл LICENSE, который не относится к совпавшему файлу.

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

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

Сначала задайте один фактический вопрос: если бы Copilot показал репозиторий до кода, стали бы мы намеренно импортировать этот фрагмент по нашему обычному процессу работы с открытым ПО? Если нет, отклоните предложение. Автодополнение не должно снижать стандарт по сравнению с тем, как разработчик открывает браузер и копирует тот же файл.

Лицензионные обязанности зависят от того, что вы выпускаете

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

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

Apache License 2.0 добавляет новые вопросы. Ее условия касаются сохранения уведомлений, копии лицензии, обозначения измененных файлов и обработки файла NOTICE, если он существует. Apache Software Foundation в собственном руководстве говорит, что ее проекты включают корректные документы LICENSE и NOTICE в дистрибутивы. Проверяющему нельзя сводить всю работу к добавлению «Apache-2.0» рядом с коммитом.

Копилефт требует передачи юристу, потому что значение имеют распространение и связь фрагмента с более крупной работой. Обязанности GNU GPL могут потребовать предоставить соответствующий исходный код и лицензировать охватываемую работу на условиях GPL при ее передаче. Приведет ли конкретный фрагмент к такому результату, зависит от фактов и требует юридической оценки. Инженерам не стоит решать этот вопрос переименованием переменных или переписыванием нескольких строк.

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

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

Для юридической проверки нужны явные условия передачи

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

Передайте случай юристу, если обнаружился хотя бы один из этих фактов:

• У источника нет лицензии, лицензии противоречат друг другу, действуют нестандартные условия или непонятен правообладатель.
• К проприетарному продукту могут относиться GPL, AGPL, LGPL, SSPL, условия source-available или другая взаимная лицензия.
• Совпадение содержит характерный алгоритм, законченную функцию, критичную для безопасности логику или крупный связный блок.
• Продукт поставляют клиентам, встраивают в оборудование, предоставляют как сетевой сервис на условиях раскрытия исходников или связывают строгими гарантиями об интеллектуальной собственности.
• Разработчик не может установить ревизию источника, применимую лицензию и обязательные артефакты соблюдения условий.

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

Порог юридической проверки должен учитывать и договоры. В некоторых корпоративных соглашениях есть гарантии, возмещение убытков, ограничения на раскрытие исходного кода или обязанности по согласованию, которые выходят за рамки авторского права. Условия GitHub различаются по тарифу и каналу покупки, а со временем меняются. Читайте соглашение именно для вашей учетной записи, а не пересказывайте рекламное обещание о защите.

В условиях GitHub для индивидуальных пользователей сказано, что результат ИИ может напоминать сторонний код или подпадать под условия открытых лицензий, а ответственность за проверку и подтверждение результата лежит на пользователе. Клиенты Business и Enterprise могут работать по другим специальным условиям продукта или Microsoft. У любого обязательства по защите есть определения, исключения и обязательные меры. Оно не разрешает игнорировать ссылку и не выполняет лицензионные обязанности за ваш процесс выпуска.

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

Сохраняйте решение внутри пул-реквеста

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

1. Разработчик останавливается на ссылке до адаптации предложения и открывает все возможные источники, включая файлы лицензий и уведомлений на указанной ревизии.
2. Разработчик сразу отклоняет тривиальные или малоценные совпадения, если проверка обойдется дороже, чем новая реализация по спецификации.
3. Для предложения, которое стоит сохранить, разработчик фиксирует принятый текст, репозиторий и файл источника, ревизию, обнаруженную лицензию, изменения, план распространения и предполагаемые обязанности.
4. Назначенный специалист по открытому ПО одобряет, отклоняет или передает случай дальше по письменным критериям. Автор не может сам утвердить собственную запись о происхождении.
5. CI проверяет наличие записи и обязательных уведомлений до слияния и еще раз при упаковке продукта.

Используйте структурированную запись, которая переживет смену IDE и сотрудников. Этот пример YAML намеренно скучен, поэтому его удобно хранить в каталоге соблюдения требований или прикладывать как структурированные данные пул-реквеста:

match_id: PCM-2026-0042
status: approved
source:
  repository: owner/project
  file: src/example.ts
  revision: 8f3c2ab
  reference_seen_at: 2026-07-27
license:
  detected: Apache-2.0
  verified_by: [email protected]
use:
  destination: services/parser/example.ts
  modified: true
  distribution: container-image
obligations:
  license_copy: THIRD_PARTY_LICENSES/Apache-2.0.txt
  notice: THIRD_PARTY_NOTICES.md
  mark_changes: services/parser/example.ts
review:
  engineering_owner: platform-team
  legal_ticket: null

Не считайте detected равным verified. Первое значение фиксирует отчет инструмента. Названный проверяющий сверяет лицензию с репозиторием и совпавшим файлом, а затем записывает ревизию. Если схема позволяет, сохраняйте оба факта.

Проверка CI не определит, охраняется ли функция авторским правом и стала ли новая работа производной. Она может обеспечить исполнение уже принятых людьми решений: утвержденный статус, заполненные обязательные поля, существующие пути к уведомлениям и связь между целевым файлом и записью. Сборка также может завершиться ошибкой, если кто-то удалит уведомление, которое все еще требует утвержденная запись.

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

Измерьте стоимость процесса до смены настройки

Режим Allow оправдан, только если проверенные совпадения дают достаточно пользы, чтобы покрыть прерывания, поиск происхождения, передачу юристам, поддержку уведомлений и проверки выпуска. Доля принятых автодополнений не учитывает большую часть этих затрат.

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

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

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

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

В конце теста оцените контроль в часах и работе над выпуском. Если одобренные совпадения редки и их дешево переписать, выигрывает Block. Если полезные совпадения регулярно встречаются в области с совместимыми лицензиями и автоматизированными уведомлениями, Allow способен окупиться.

Лицензионная проверка не заменяет инженерную

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

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

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

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

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

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

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

Следующий текст подойдет как отправная точка для компании с проприетарным ПО:

Public code matching is blocked unless a repository owner has an approved exception.
In an excepted repository, a developer may not merge a referenced suggestion until an
open source reviewer verifies its source, revision, license, planned use, and required
notices in a provenance record. Unknown, custom, conflicting, or reciprocal terms go
to Legal. Security sensitive or nontrivial complete implementations require both a
technical owner and open source review. Missing provenance means reject or rewrite.
Release builds must include every artifact named by approved provenance records.

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

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

В обучении стоит показать реалистичную ссылку и потребовать от разработчика отклонить либо задокументировать ее. Слайд с фразой «уважайте открытый код» не учит искать уведомление на уровне файла или записывать ревизию. Разберите первые несколько случаев вместе, а затем опубликуйте утвержденные записи как внутренние примеры.

Team & AI Audit от oleg.is может сопоставить эти средства контроля с общим процессом работы агентов программирования, в том числе найти места, где время проверки съедает ожидаемую экономию зарплат. Полезный результат здесь не выглядит как безусловное «да» или «нет». Нужны настройка, владелец исключения, цепочка доказательств и проверка выпуска, соответствующие реальному способу поставки продукта.

Настройка должна соответствовать вашей способности сохранять доказательства

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

Когда эти части заработают, режим Allow станет разумным выбором для отдельных репозиториев. Он дает команде информацию, которую Block скрывает, и позволяет осознанно решать вопрос повторного использования. Цена в том, что каждое полезное совпадение попадает в процесс стороннего кода, даже если оно пришло в виде нескольких удобных строк.

Не принимайте более тихую IDE за меньший риск. Режим Block сокращает один вход, но не обнаруживает фрагменты из браузера, измененные предложения, частные источники и код за пределами индекса GitHub. Сохраняйте обычную проверку кода, анализ состава, тестирование безопасности и обучение разработчиков.

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

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

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

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

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

Первое действие вполне конкретно: выберите один репозиторий, уточните, какими интерфейсами Copilot пользуются его разработчики, и проведите учебную ссылку на публичный код через весь процесс. Если никто не может сказать, где будут жить ревизия источника, одобрение и отправленное уведомление, оставьте фильтр в режиме Block. Отсутствующая запись уже дает ответ.