Agent Capability Recertification в 2026: как периодически пересматривать права агента, а не только выдавать их

Короткая версия

Хорошая capability-recertification policy в 2026 обычно отвечает:

1. Какие capability нужно пересматривать
2. Как часто проходит recertification
3. Кто подтверждает необходимость доступа
4. Что происходит при failed recertification
5. Как это связывается с incident и audit history

Что особенно важно

• recertification полезен для long-lived grants;
• подтверждать надо не только наличие owner-а, но и актуальную business need;
• capability лучше пересматривать по risk tier;
• непрошедший recertification grant должен либо сузиться, либо исчезнуть.

Зачем capability регулярно пересматривать, если они уже когда-то были одобрены?

1. Recertification особенно нужен для long-lived capability

Обычно это:

• tenant-scoped privileges;
• broad write permissions;
• manual override access;
• elevated retrieval access;
• cross-system tool bundles.

Именно они чаще переживают исходный процесс и становятся legacy-risk surface.

2. Проверять нужно не только owner-а, но и смысл доступа

Полезные вопросы:

• capability всё ещё нужен для текущего workflow?
• scope доступа не стал слишком широким?
• есть ли более узкая альтернатива?
• были ли incidents или misuse cases?
• какой risk tier у этого grants сейчас?

Так recertification не сводится к формальному "да, owner существует".

3. Recertification должен иметь outcome, а не только отметку

Полезные исходы:

• renew unchanged;
• narrow scope;
• shorten duration;
• require extra approval for use;
• revoke.

Иначе пересмотр превращается в декоративный checkbox.

4. Частота зависит от risk tier

Часто разумно:

• high-risk grants — чаще;
• medium-risk grants — периодически;
• low-risk read-only grants — реже.

Это снижает административную нагрузку, не убивая контроль.

5. Что особенно часто ломают команды

Recertification only on paper

Процесс описан, но реально не запускается.

Owner confirms by habit

Никто не пересматривает scope и necessity.

No link to incidents

Прошлые misuse cases не влияют на пересмотр.

All grants reviewed equally

Нет risk-based prioritization.

Failed review without action

Непрошедший grant формально "замечен", но не меняется.

6. Какие метрики полезны

Полезно считать:

• recertification completion rate;
• grants narrowed or revoked after review;
• overdue grants awaiting recertification;
• high-risk grants without current owner confirmation;
• incidents involving stale-certified capability;
• average grant age by risk tier.

Пример recertification record

grant:
  capability: refund_override
  risk_tier: high
  last_recertified_at: "2026-04-01"
  next_recertification_due: "2026-05-01"
  owner: support_ops

Простой overdue check

def needs_recertification(grant, now):
    return grant["next_recertification_due"] <= now

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