何でもインストールし、何でも呼び出し、どこにでも書き込めるエージェントは、壁が本物であって初めて安全です。Kortixでは、その壁はエージェントの下、プラットフォーム内にあります。プロンプトで言いくるめて突破することはできません。
セッションは共有ランタイム内のタブではありません。それ自体が専用マシンであり、データベースによって2つのセッションが同じマシンを持てないようになっています。自分の2つのセッションを分離する仕組みは、異なる顧客同士を分離する仕組みと同じです。
1つのセッション内
決して入ってこないもの
ツールが実際の作業をするには実際の認証情報が必要です。問うべきは、マシンがそれを保持するかどうかではなく、どのマシンがどのキーを保持し、誰が決定し、何が決して入らないかです。
01
プロジェクトごとに導出したキーでAES-256-GCM暗号化。
02
ユーザーのロールとエージェントが宣言した権限の両方で許可される必要があります。
03
起動時に、名前でセッションへ配置されます。tmpfs上でモード0600です。
04
ツールは環境変数から読み取ります。プロンプトには書き込まれません。
05
シャットダウン時にファイルを消去し、マシンも同時に破棄します。
多くのAIツールは、開始したユーザーがアクセスできるものをエージェントにも与えます。Kortixは違います。エージェントIDは独自のポリシーを持ち、それ自体で評価されるため、許可していないものへ権限を引き継いで到達することはできません。
主体
リソースタイプ
権限は、プリンシパル、アクション、リソース種別の組み合わせに付与されます。
組み込みロール — すべてのプランで利用可能
account
project
Enterprise
Available on Enterprise, and on a self-hosted instance with an Enterprise license. The built-in roles above are free on every plan.
サービスアカウントは、帽子をかぶった人間用トークンではなく、アカウントが所有する正式なマシンIDです。ポリシーは直接付与され、リクエストはそのポリシーだけに基づいて評価されます。作成者の権限を引き継ぐことはありません。
ユーザーやグループを、プロジェクト内の指定したエージェントやスキルに限定できます。マーケティング部門にはこのエージェントとそのスキルだけを許可し、それ以外は許可しない、といった設定が可能です。範囲を指定しないものはプロジェクト全体に適用されるため、限定は任意です。
承認は管理パネルの奥にある設定ではありません。kortix.yaml内のブロックとして、他のすべてと一緒にバージョン管理されます。どのツール呼び出しを実行し、どれを人の確認で止め、どれを完全に拒否するかを定義します。
# reads run; writes and destructive calls stop for a humanpolicy: default_mode: risk policies: # a name-only rule cannot gate the target — conditions can - match: gmail.send_email action: require_approval conditions: - arg: to match: /@example\.com$/ # anything else through this tool is refused outright - match: gmail.send_email action: block # whole connectors can be gated with one glob - match: stripe.* action: require_approval3つのアクション
always_run、require_approval、block。ルールは完全修飾されたツールパスに対するglobに一致するため、1行で単一の呼び出しからコネクター全体まで対象にできます。
ツールだけでなく対象をゲートする
「エージェントがメールを送信してよいか」だけではガードレールになりません。条件は引数に一致するため、「これらのアドレスにのみ」と指定できます。評価できない引数は安全側で拒否されます。
包括的な「常に許可」はなし
ゲートされた呼び出しはすべて、引数を目の前に表示して個別に承認します。後続の呼び出しが異なる引数を隠れて使える、セッション全体への許可はありません。その近道はUIだけでなく、強制適用地点から削除されています。
望むデフォルトを設定
default_mode: riskでは、読み取りは実行し、書き込みや破壊的な呼び出しは人に送ります。ポリシーブロックのないプロジェクトは従来の寛容なデフォルトを維持するため、明示的に設定してください。
エージェントは自分のブランチで自由に作業できます。mainへ反映することは別の権限であり、意図的に委譲しない限り持ちません。その委譲自体も、誰かが承認する変更です。
すべての編集は、そのセッション用に切られたブランチに反映されます。エージェントの作業が他のセッションやmainから見えることはありません。
エージェントがマシンの破棄後も残したい変更を作ると、コミットしてmain宛ての変更リクエストを作成します。入口はこれだけです。
変更リクエストは差分です。エージェントが自分のプロンプトを書き換える場合も、コード変更と同じようにレビューします。実際に変更だからです。マニフェストが検証に通らない変更リクエストは、まったくマージできません。
マージは独立した権限であり、管理者が付与しない限りすべてのエージェントに拒否されます。その付与はkortix.yamlに記録されるため、エージェントが自分の権限範囲を広げるには、他者が承認する変更リクエストが必要です。
すべてのアカウント操作とエージェント操作は、すべてのプランで記録されます。誰がその記録を読めるか、エクスポートできるか、ストリーミングできるかはプランで決まり、記録の有無では決まりません。
同じ製品を、マネージドクラウド、自社ネットワーク内のスタック、独立したデプロイとして提供します。オープンソースなので、信頼する対象は読めるコードです。
マネージドサービスです。コントロールプレーンとコンピュートは私たちが運用し、会社の業務はあなたが運用します。
管理対象クラウドと同じイメージを使い、あなたの環境で1つのDocker Composeスタックを実行します。データベースとファイルは、あなたが管理するディスク上に置かれます。
A single-tenant deployment inside your own network. Isolated topologies are scoped with us rather than self-served.
実際の状況
ISO 27001やHIPAAは取得しておらず、取得しているかのように示すこともしません。報告書が公開されたら、その日にこの表示を更新します。それより前には更新しません。
脆弱性について公開Issueを作成しないでください。影響を受けるバージョンまたはコミット、再現手順、影響範囲を添えて、セキュリティ窓口へメールしてください。