Баги контроля доступа — первая строчка в OWASP Top 10. Никто не спорит, что пользователь не должен читать чужие данные. Проблема в другом: правило «проверь права» живёт где угодно, только не в коде. В промпте, в чеклисте, в надежде, что каждый разработчик запомнит. С AI-кодингом эта схема развалилась окончательно. Можно забить все CLAUDE.md, написать тщательный system prompt — модель напишет 16 тысяч строк, и вопрос останется: как ты знаешь, что код делает то, что нужно?
Автор статьи предлагает другой путь — структурное обратное давление (backpressure) вместо бесконечного улучшения агентов. Идея простая: мы не просим модель помнить инвариант, мы делаем так, чтобы нарушить его было трудно случайно. Инструмент для этого — Shen-Backpressure, построенный на языке Shen (статически типизированный Lisp с секвенциальным исчислением). Вы пишете спецификацию доступа один раз в specs/core.shen, а кодогенератор shengen превращает её в типы-стражи для Go или TypeScript.
Пример: чтобы получить доступ к ресурсу, нужно пройти цепочку jwt-token → authenticated-user → tenant-access → resource-access. Каждый шаг — отдельный тип, конструктор которого проверяет условия. В Go поля структуры неэкспортируемые — создать значение напрямую нельзя. NewTenantAccess откажется работать, если isMember == false. В демо это видно: Алиса из Acme получает доступ к Acme, но запрос к Globex падает ещё на этапе сборки. Не в рантайме — компилятор отказывается.
Обычный if в каждом хендлере легко забыть. Shen-Backpressure концентрирует проверку в одном месте — на границе создания защищённого типа. Модель может написать любой код, но если она пытается пропустить цепочку, build просто не соберётся. Это и есть то самое «нет» от компилятора, которое работает как backpressure.
У подхода есть цена: нужно писать и поддерживать спецификацию, генератор и аудит-скрипты. Обход теоретически возможен — через рефлексию в Go, неверный SQL-запрос. Но автор честно говорит: цель не сделать нарушение невозможным, а сделать его практически невозможным случайно. Для AI-генерируемого кода это радикально меняет игру. Забытая проверка, утёкший tenant ID, скопированный и недоработанный хендлер — всё это становится сложно внести по ошибке.
Главный тезис статьи: для production-кода, написанного AI, нужно лучшее обратное давление, а не лучшая модель. Тесты проверяют то, что вы додумались проверить. Компилятор и типы-стражи проверяют то, что заложено в спецификацию. И зелёный CI с прошедшими гейтами — это артефакт, который можно показать аудитору. Гораздо убедительнее, чем просто «мы использовали сильную модель».