На третью ночь на странице была та же самая строка, которую я прочитал двумя вечерами раньше: policy.deny агент=инструмент синхронизации каталога=inventory.write Reason=not_in_allowlist Catalog-sync записывал данные в инвентарь каждые двадцать минут в течение шести месяцев. Это было ...
На третью ночь на странице была та же самая строка, которую я прочитал двумя вечерами раньше:
policy.deny агент=инструмент синхронизации каталога=inventory.write Reason=not_in_allowlist
Catalog-sync записывал данные в инвентарь каждые двадцать минут в течение шести месяцев. Это все равно должно было случиться. Список не изменился. Бизнес имел.
Мы владели уровнем разрешений для внутренней экосистемы агентов — на тот момент их было около дюжины, каждый из которых был подключен к нескольким внутренним API. Первая версия представляла собой статический список разрешений: агент X получает эти шесть инструментов, никаких переговоров, никаких решений во время выполнения, проверка проста. Примерно пять месяцев это выглядело как зрелый выбор. Затем в одном выпуске служба была разделена на две части и вместе с ней перемещена половина названий инструментов. Намерение не изменилось. Каждый из этих запросов был законной работой. Половина из них начала возвращаться с отказом, и отказы поступали в виде страниц, потому что цикл согласования, которому отказывают, продолжает спрашивать, пока человек не остановит его.
Вот так я просыпался три ночи подряд из-за списка разрешений, который был технически правильным и бесполезным с точки зрения эксплуатации.
Мы потратили неделю на исправление списка, прежде чем признали, что модель неверна, и перестроили его как динамическую авторизацию: когда агент