Разница между фильтрами и стенами

Вы создаете ИИ-агента с доступом к вашим данным. У вас есть два варианта обеспечения безопасности: вы можете фильтровать данные или возводить вокруг них «стены».

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

Это выглядит одинаково, пока что-нибудь не сломается.

Недавно я создал систему, которая превращает 1,2 миллиона слов в базу знаний. Для управления данными я использовал Supabase. Я хотел, чтобы мои ИИ-агенты видели только публичный контент.

Я использовал стандартное представление (view) Postgres для фильтрации данных:

CREATE VIEW public_seeds AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

Это выглядит правильно. Но здесь есть огромный изъян. По умолчанию представление Postgres выполняется от имени владельца, а не того, кто его вызывает. Владелец представления часто имеет полный доступ. Это означает, что ваши политики Row Level Security (RLS) не применяются к этому представлению.

Вы не построили стену. Вы построили фильтр.

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

Postgres 15 решил эту проблему с помощью опции security_invoker.

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

Правильный способ:

CREATE VIEW public_seeds
  WITH (security_invoker = true)
AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

Теперь стена стала структурной. Даже если разработчик напишет плохой запрос или некорректное соединение (join), политика RLS защитит таблицу.

«Этого не должно случиться» — полагается на то, что всё работает идеально. «Этого не может случиться» — полагается на вашу архитектуру.

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

Три вещи, которые стоит проверить в вашей настройке:

Источник: https://dev.to/chadtdyar/the-difference-between-this-shouldnt-happen-and-this-cannot-happen-in-ai-content-pipelines-1g0p

Дополнительное обучающее сообщество: https://t.me/GyaanSetuAi