Корпоративний · Управління агентами

Ваші агенти мають імена та власників
і вимикач.

До 2027 року флоти — а флот анонімних процесів є зобов'язанням. LeanCTX робить кожного агента зареєстрованою ідентичністю: унікальною, власністю людини, керованою протягом життєвого циклу, засвідченою та відкликаною — з кожним переходом у незмінному аудиторському журналі.

Модель

Ідентичність відповідає. Роль виконує.

Ролі залишаються багаторазово використовуваними профілями дозволів. Ідентичність додає підзвітність поверх: agent_id, власник, статус, прив'язка ключа, атестація, серцебиття. Чотири властивості роблять флот керованим.

Зареєстрована ідентичність

Кожен агент — це запис: стабільний agent_id, роль, прив'язка ключа Ed25519, дата створення. Більше жодних здогадок, який процес що зробив — реєстр є джерелом правди про те, хто існує.

Власністю завжди

Реєстрація без людського власника відхиляється. Підзвітність структурна: кожна аудиторська запис, кожна подія життєвого циклу, кожен пакет доказів простежуються до особи, яка відповідає за агента.

Відкликано в одній транзакції

Призупинити агента або вивести власника з системи та призупинити весь його флот атомарно — кождого призупинення індивідуально аудитують. Виведення з експлуатації є остаточним і записує завершальний запис аудиту.

Атестовано, чесно

Бінарні хеші та хеші конфігурацій ролей під час реєстрації та кожного серцебиття. Відхилення виявляється негайно (код виходу 3) — оновлення, редагування конфігурації або маніпуляція. Ми документуємо те, проти чого це НЕ захищає.

На практиці

Флот з п'яти команд.

Усе орієнтоване на CLI та чесне щодо кодів виходу, тому ваші конвеєри та моніторинг можуть діяти на його основі.

$ lean-ctx agent register --id ci-reviewer-1 --role reviewer --owner alice@org
registered: ci-reviewer-1 (role reviewer, owner alice@org)
spiffe id: spiffe://org.example/agent/reviewer/ci-reviewer-1

$ lean-ctx agent heartbeat ci-reviewer-1     # liveness + drift; exit 3 on drift

$ lean-ctx agent offboard-owner alice@org --reason "left company"
suspended 2 agent(s): ci-coder-1, ci-reviewer-1

$ lean-ctx agent check ci-reviewer-1         # enforce-path decision point
ci-reviewer-1: DENIED — suspended: left company   # exit 1

Кожен перехід записує доказний аудит-запис — зареєстровані, призупинені, відновлені, виведені з експлуатації є стандартизованими типами подій (OCP Part 4), тому історія ідентичності потрапляє у ваші пакети доказів автоматично. Повний модель та модель загроз: документація щодо ідентичності агента.

"Що відбувається, коли хтось звільняється?"

Їхні агенти зупиняються. Механічно. Виведення власника з системи призупиняє кожного активного агента цього власника в одній заблокованій транзакції — підключено до вашого потоку депровіжнування SCIM або запущено зі списку контрольних питань для звільняючихся. Агенти-сироти — це забуті облікові записи служб епохи агентів; LeanCTX робить їх структурно неможливими.

FAQ

Що питають команди платформ.

Чому агентам потрібні ідентичності, якщо у них вже є ролі?

Роль говорить про те, що може робити процес; ідентичність говорить, хто несе за це відповідальність. З флотами важливі операційні питання: кому належить цей агент, коли він востаннє був активним, хто його вимкнув і чому, що станеться з його дозволами, коли звільняється власник? Реєстр відповідає на них механічно — ідентичність (хто) залишається окремо від ролі (що), тому ролі залишаються повторно використовуваними профілями.

Що таке проблема агентів-сиріт?

Агент, чий людський власник залишив компанію, але який продовжує працювати за його обліковими даними — версія епохи агентів забутого облікового запису служб, тільки він читає код і виконує команди. LeanCTX структурно це вирішує: власники є обов'язковими при реєстрації, і одна команда (або ваш потік депровіжнування SCIM) призупиняє весь активний флот власника в одній заблокованій транзакції, кожен призупинення аудітується.

Як працює життєвий цикл?

active → suspended ⇄ active → decommissioned. Призупинення містить причину і є зворотним; виведення з експлуатації є остаточним за задумом — запис ніколи не видаляється і ніколи не реактивується, оскільки ідентичність є частиною історії аудиту. Кожен перехід записує доказний аудит-запис, використовуючи стандартизовані типи подій (agent_registered, agent_suspended, agent_resumed, agent_decommissioned — OCP Part 4), тому зміни ідентичності відображаються у пакетах доказів автоматично.

Що насправді підтверджує атестація?

Реєстрація та кожен «серцебиття» хешують виконуваний бінарний файл і активний файл ролі. Змінений хеш означає, що щось змінилося — оновлення, редагування конфігурації або маніпуляція — і виявляється як дрейф з ненульовим кодом виходу, на який може сповістити ваш моніторинг. Це виявлення дрейфу, а не віддалена атестація: зловмисник із повним контролем хоста може підробити хеші, і наша модель загроз прямо це зазначає. Це доповнює, а не замінює, зміцнення хостів та підписання коду.

Як це інтегрується з нашим IAM?

Три гачки. SPIFFE: кожен запис відображається на spiffe://<trust-domain>/agent/<role>/<agent_id>, тому ідентичність K8s workload (SPIRE) та LeanCTX є однією назвою. SCIM: підключіть ваш потік депровіжнування до виклику виведення власника з системи. Режим примусу: API перевірки — це єдина точка прийняття рішень — зареєстровані або призупинені агенти відхиляються; почніть у режимі моніторингу, перейдіть до режиму примусу, коли флот зареєстровано.

Керуйте робочою силою агентів.

Зареєструйте свого першого агента за хвилину, локально та безкоштовно — або обговоріть розгортання флоту зі SCIM та SPIFFE в циклі.