Стоящий доступ — архитектурный дефект: идентичность хранит право в паузе между задачами. Пользователь не работает, агент не в вызове, а разрешение все еще есть. Этот разрыв между «имеет право» и «сейчас выполняет задачу» — и есть поверхность атаки. JIT убирает разрыв, делая доступ следствием задачи.
Standing privilege как атака-поверхность
Проблема не в токене, а в его времени жизни. Standing token на месяцы переживает смену владельца, ротацию команды и забытые интеграции. Украденный standing token сразу дает все права, без эскалации. Forrester в 2025 назвал ZSP новым стандартом именно потому что standing privilege — dormant attack surface с гарантированным окном эксплуатации.
Почему агенты — худший кейс для standing
- Долгие сессии. Агент может висеть часами, ретраить и возобновляться после колбэка — постоянный credential становится unattended authority.
- Cross-tool. Один агент читает из одной системы, пишет в другую, хранит промежуточное в третьей — bundle standing токенов с планировщиком сверху.
- Replay. Нормальное поведение агента — быстрые tool calls пачками — неотличимо от replay украденного токена без привязки к задаче.
- Размытая идентичность. Действие делает софт, а право — от человека/процесса. Модель «агент как пользователь» теряет delegation chain:
human + workflow + intent.
Агентам нужен не «доступ к GitHub», а «право сделать этот action над этим ресурсом для этой задачи до этого времени».
Zero Standing Privilege — определение
ZSP: идентичность начинает с нуля, грант появляется только когда есть причина, только на нужное действие, только на нужный ресурс, только на окно задачи — потом исчезает. JIT — механизм, ZSP — состояние где JIT единственный путь. Полный ZSP enterprise-wide редок, цель 2026 — JIT everywhere-it-matters, ZSP для high-risk сегментов (привилегированные операторы, финансовые системы, AI-агенты).
4 паттерна JIT
- Time-bounded access. Каждый грант с
expires_at(15–30 мин для рутины, 1–4 часа для инцидента, 8–12 часов для смены). Истечение enforced платформой, не дисциплиной пользователя. - Workflow-attested elevation. Запрос через approval workflow с обоснованием (что, зачем, какой риск). Легкий — auto-approve менеджера, тяжелый — security review. Обоснование — evidence для расследования.
- Risk-evaluated approval. Автоматика учитывает сигналы риска (чувствительность данных, аномалия поведения), а не только подпись менеджера.
- Auto-revocation. Энтайтлмент снимается по таймеру или по сигналу «задача завершена». Без зависимости от «верну и сниму» — иначе накапливается residual standing.
Для агентов это per-invocation: каждый вызов — новый scoped delegation token (user-on-behalf-of, узкий scope, короткий TTL), auto-revoked по завершении.
6 вопросов перед грантом + кэш-ключ
Перед выдачей система спрашивает:
- От чьего имени действует агент?
- Что именно пытается сделать (intent как policy input)?
- Какой точный action и ресурс?
- На какой scope и tenant?
- Есть ли consent/approval reference?
- На сколько времени?
Кэшировать решение можно только с ключом identity + workflow_id + action + resource + scope + consent + expires_at. Без expires_at кэш воскрешает истекшее право, без workflow_id — одна задача одалживает права у другой. Это не кэш, а privilege laundromat.
Где Codenik: JIT enforcement point
Codenik применяет ZSP на границе инструментов: gateway — choke point для каждого tools/call. Агент аутентифицируется в gateway, gateway выпускает per-invocation грант с authorization_details (RFC 9396), проверяет политику, пробрасывает scoped секрет и отзывает по истечении. Агент не хранит standing токен, а получает authority на задачу. Тот же PDP отвечает на вопрос «должно ли это действие быть разрешено сейчас?» — не «доверяем ли агенту вообще?».
Короткий вывод
Standing privilege — ставка что токен не украдут до ротации. JIT делает ставку ненужной: доступ живет минуты, а не месяцы, и привязан к задаче. Начните с high-risk агентов, введите 4 паттерна и 6 вопросов — и blast radius сожмется до окна задачи.