あなたの AI に、人事制度はありますか? 7 段階、1 つのランタイム。既存ベンダーはそれぞれ 1 段しかカバーしていません。
どの人間組織にも、従業員を管理する 7 段階のライフサイクルがある。面接、オンボード、 試用期間中の観察、実績評価、信頼に基づく昇格、行動が揺らいだ時の処分、関係終了時の退職。 Aegis は、同じ 7 段階を AI エージェント向けに、1 つのランタイムとして構築している。 各段階は具体的な機能に対応し、それらが 1 つの強制レイヤーに統合される。
purpose を宣言）、
オンボード（scope が閲覧可能フィールドを制限）、
試用期間（各アクセスをローカル監査ログ、または FULL モードでは aegis-core gateway に記録）。
継続評価・動的昇格・自動処分・証明可能な退職といった後段の機能は現行 SDK の主張ではなく、カテゴリのロードマップです。
現時点で証明できる内容は プロダクト と
LITE / FULL モード を参照してください。
AI エージェントを雇う 7 段階
-
採用 (Hire)
身元 + 契約すべてのエージェントは、宣言された身元、明示された目的、コントロールプレーンへの 正式な登録と共に入場する。署名された「何を試みてよいか」の契約がなければ、 エージェントは動かない。匿名のエージェント、影のエージェント、 目的を 1 文で述べられないエージェントは、ここには存在しない。
-
オンボード (Onboard)
最小限のツール、入館証初日、エージェントは宣言された仕事を始めるために本当に必要な、最も狭い権限セット だけを受け取る。将来必要になるかもしれない権限ではない。今日、目の前のタスクのために 必要な権限。それ以上はない。権限の拡大は後で、信頼を獲得した結果として行われる。 既定でアクセスが与えられることはない。
-
試用期間 (Probation)
狭い職務、密な観察試用期間中、エージェントの各データアクセスが記録される。この観察は、 四半期ごとにレビューするログではない。出荷中の SDK では、これは追記専用の監査レコードであり、 LITE モードではローカルに、FULL モードでは aegis-core gateway に書き込まれ、そこで改竄検知可能な サーバー検証済みチェーン（
/audit/verify）になる。新しいエージェントの信頼度はゼロから始まる。 信頼は行動の結果であり、初期値ではない。 -
継続評価 (Evaluate)
パフォーマンスレビュー、連続的に評価は年に一度のイベントではない。すべての行動で再計算される、連続的に更新される シグナルである。成功した結果はエージェントの評価を上げる。異常な振る舞いは下げる。 シグナルはコントロールプレーンが保持し、人間のレビュアーを介さず、 ランタイムが下流で行うすべてのポリシー判断から利用できる。
-
昇格 (Promote)
権限の拡大、実績によるエージェントの評価シグナルが閾値を超えると、新しい権限が利用可能になる。 この昇格は手動チケットではない。コントロールプレーンがランタイムで、 時間経過での実績行動に基づいて下す判断である。新しい権限はスコープが限定され、 監査され、取り消し可能である。エージェントは権限を永久に保持するわけではない。 獲得し続ける限り、保持する。
-
疑義対応 (Review & Discipline)
停職、降格、追加監査行動が揺らいだ時、コントロールプレーンは人間が気づく前にエージェントのスコープを 削減する。削減は即時、自動、監査可能。追加監査が走る間の一時的な制限になることもあれば、 異常が深刻であれば恒久的な降格になることもある。後から決めることは何もない。 対応は、元のリクエストと同じ判断パスの中で起きる。
-
退職 (Offboard)
入館証剥奪、残存リスク消去エージェントがサービスを離れる時、アクセスは取り消され、到達できるデータは、初日から エージェントを律してきたのと同じ目的・スコープのポリシーで境界づけられる。目指すのは、 エージェントが行動する能力の証明可能な消失と、在任中に何に触れたかの明確な記録である。 退職はクリーンアップ作業ではなく、ライフサイクルにおける第一級のイベントである。なお、この段階は カテゴリのロードマップに含まれるものであり、出荷中の SDK が強制するのはデータ境界であって、 秘密のフルライフサイクル管理ではない。
既存ベンダーが届く範囲
7 段階のライフサイクルは、コンセプトとしては Aegis 固有のものではない。 完全な実装としては、Aegis 固有である。隣接空間の既存ベンダーは それぞれ正確に 1 段階だけをカバーする。彼らのアーキテクチャが ライフサイクル上の特定の点に最適化されており、他の段階に自然には拡張できないためだ。
| ベンダー | カバー範囲 |
|---|---|
| Okta | 段階 1 (Hire — 身元管理) |
| Kong | 段階 2 (Onboard — ツールルーティング) |
| Palo Alto Networks | 段階 6 部分 (Discipline — 異常検知) |
| CrowdStrike | 段階 6 部分 (Discipline — エンドポイント範囲) |
| Microsoft Purview | 段階 3 + 5 部分 (分類、ラベリング) |
| HashiCorp Vault | 段階 2 部分 (Onboard — 秘密配布) |
| Aegis | 段階 1 から 7 まで、1 つのランタイムとして |
身元中心ベンダー (Okta)
セキュリティの原子単位は身元である、という前提で構築されている。段階 1 が彼らの本拠地。 段階 2 から 7 は、別の原子単位 (行動、データ、時間経過の振る舞い) を必要とし、 彼らの販売体制とランタイムはそれを表現していない。人事層とパートナー連携はできるが、 既存ポジションを放棄せずに人事層そのものになることはできない。
ゲートウェイ中心ベンダー (Kong, Vault)
リクエストのルーティングと秘密配布を中心に設計されている。段階 2 が本拠地。 オンボードはルーティング問題なので対応できる。試用期間、評価、昇格は 連続した行動の問題であり、ゲートウェイは設計上、リクエスト間で状態を保持しない。 状態を追加するには、反対の原理で作られた 2 つ目の製品が必要になる。
異常検知ベンダー (Palo Alto, CrowdStrike)
悪意ある主体を、行動後に特定するよう設計されている。段階 6 が本拠地。 彼らのパターンは、時間経過で観察可能な長寿命の主体 (ホスト、エンドポイント、ユーザー) を前提とする。主体が一時的な AI エージェントで、1,000 の並行インスタンスを持つ時、 その前提は崩壊する。行動が分類される前に、検知予算が尽きる。
分類中心ベンダー (Microsoft Purview, Adobe)
データは分類され保持されるために存在する、という前提で構築されている。 段階 3 と 5 (部分) が本拠地。彼らのビジネスモデルは、データが分類・ラベリング できるほど長く存続することに依存する。Aegis はデータの消滅を第一級の状態として扱う。 これは反対のロードマップではない。反対のビジネスモデルである。
なぜ Aegis だけが 7 段全部を持っているのか
7 段階は、紙の上では分離可能に見える。実務では分離不可能だ。身元が採用時に正式宣言されていない エージェントを、最小権限でオンボードすることはできない。試用期間中の監査証跡が 再構築可能でなければ（改竄検知は FULL モードで aegis-core gateway 経由）、連続的な評価はできない。コントロールプレーンが評価から 認可へと状態を運ばなければ、動的な昇格はできない。処分とリクエストが別ランタイムで 処理されるなら、元のリクエストと同じ判断パスでの処分はできない。そしてデータが最初から ポリシーで包まれていなければ、証明可能な消失を伴う退職はできない。
Aegis は、7 段階を 7 つの製品としてではなく 1 つのライフサイクルとして扱う、 唯一の既存ランタイムである。強制の単位は主体 (誰が) ではない。1,000 のインスタンスを持つ 主体は単位になりえないからだ。強制の単位は客体 (どのデータが、どの目的で、 どのポリシーを運んで) である。ライフサイクルのすべての段階が、同じ客体層から読み、 書き、その境界に従う。この統合が、7 段階すべてを 1 つのランタイムで可能にしている理由である。 同時に、競合が基盤を作り直さずに段階 2 から 7 に到達できない理由でもある。
私たちは競合に作り直しを期待しない。彼らが得意とすることを彼らが続けることを期待する。 そして、人事層が彼らの隣に立つ新しいカテゴリになることを期待する。そのカテゴリを 作っているのが Aegis である。