セキュリティ姿勢の適用はワークスペース設定を変更するため、ステップ 2 と 5 には
Developer ロールが必要です。ガードレールの Matches フィード(ステップ 4)は
すべてのメンバーに開放されています;ファイアウォールの Events フィードにも
Developer が必要です。
5 ステップでオンにする
API キーを取得する
まだ持っていない場合は、キーを作成します —
API キーを取得するを参照してください。
保護したいエージェントにこのキーを渡します。以下のすべてはワークスペースに
バインドされているため、同じ姿勢がその中のすべてのキーをカバーします。
セキュアエージェント ベースラインを適用する
コンソールで Firewall → Posture を開き、
balanced
自律性レベルを適用します
(Developer ロール)。ひとつのトランザクションでファイアウォールとガードレール姿勢の両方を設定します:
ツール呼び出しは audit され、PII はフラグされ、最も破壊的なアクション
(破壊的シェルなど)は deny されます — そのため広く強制する前に観察します。
ワンクリック取り消しのある単一のスイッチです。(何もブロックしないパスについては、
permissive から始めます。)以前と全く同様にリクエストを送信する
呼び出しについて何も変わりません。同じキー、同じ OpenAI 形式を使用します:リクエストは通過します。
balanced ではブロックされません — 観察されます。
メールはフラグされ、エージェントが行うすべてのツール呼び出しが記録されます。エージェントが実際に何をしたかを見る
2 つのフィード、両方ともワークスペーススコープ:
- Firewall → Events / Runs — エージェントが行ったすべてのツール呼び出し、 その判定、そしてどのサーフェスにヒットしたか(アドバタイズしたツール、 モデルが発行した呼び出し、MCP ディスパッチ、またはアウトバウンド宛先)。
- Guardrails → Matches — 発火したすべてのルール、フラグされたメールなど、 ガードレールとアクションごとにグループ化されています。
強制するために強化する
フィードが正しく見えたら、同じ Firewall → Posture ページで自律性レベルを
tight に切り替えます(Developer ロール)。これで強制がライブになります:PII はモデルが見る前にマスクされ、シークレットは
リクエストからブロックされ、破壊的なシェル呼び出しと SSRF egress は deny されます。
deny されたツール呼び出しは HTTP 400 firewall_blocked として返ってきます;
ブロックされたプロンプトは HTTP 400 guardrail_blocked として返ってきます —
そしてブロックはクォータを消費しません。アプリケーションの変更は不要です —
次のリクエストから統制されます。今オンにしたもの
| レイヤー | balanced の下 | tight の下 |
|---|---|---|
| ガードレール(テキスト) | PII がフラグされる(audit-only) | PII がマスクされ、シークレットがブロックされる |
| ファイアウォール(アクション) | Audit 済み;破壊的シェルが deny | デフォルト deny;破壊的シェル + SSRF egress が deny |
| 可視性 | フル — Events + Matches | フル — Events + Matches |
厳しすぎましたか?
すべての自律性変更はワンクリック取り消しの単一トランザクションなので、 Firewall ページ(または取り消し API)から直前の姿勢にそのままロールバックできます。 いつでもより緩いレベル(balanced または permissive)を再適用することもできます。
次のステップ
セキュアエージェント ベースライン
各自律性レベルが設定するもの、および適用前にシミュレートする方法。
強制モード
Observe → shadow → enforce、安全なロールアウトの詳細。
ガードレール
ベースラインを超えた独自のコンテンツルールを作成する。
エージェントファイアウォール
ツール許可リスト、引数チェック、egress ルールを作成する。
