ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-04-27上級

Antigravity Agent に書き込み権限を安全に渡す — Permission Boundary の本番設計

AIエージェントに本番DBやデプロイ権限を任せる際の Permission Boundary 設計を徹底解説。4階層モデル・ドライラン・承認キュー・監査ログまで実装パターンを示します。

antigravity435agents90security13permission-boundaryproduction59architecture13

プレミアム記事

import Image from 'next/image';

最初に正直に書きます。私は Antigravity のエージェントに本番データベースの UPDATE 権限を渡して、ユーザーテーブルの 1,200 行に意図しない値を書き込んでしまったことがあります。幸いトランザクションで囲んでいて即ロールバックできたのですが、あの「履歴を巻き戻す」という意思決定をした瞬間の冷や汗は、今でもはっきり覚えています。

この事故から学んだのは、ガードレールやサンドボックスだけでは足りないということでした。エージェントは「書き込んでいい場所」と「書き込んではいけない場所」を文脈で判断できません。許された範囲を Permission Boundary(権限境界) として外側から強制する仕組みが、本番運用には必ず必要です。

この記事は、その Permission Boundary をどう設計し、どう実装するかをまとめたものです。私が実際に Antigravity の Agent 実行環境 と組み合わせて運用している構成をベースにしています。

なぜサンドボックスだけでは不十分なのか

Antigravity のサンドボックス機能 は、ファイルシステムやネットワークの分離には有効です。しかし本番運用で起こる事故の多くは、サンドボックスの内側で起きます。

具体的には次のようなケースです。

  • エージェントが正しい認証情報で本番 DB に接続しているが、WHERE 句を間違えて全行更新してしまう
  • ステージング用の S3 バケットに書くつもりが、ハードコードされた本番バケット名を残してしまう
  • デプロイトリガーを叩く API キーが渡されており、テスト用と思って実行したら本番にデプロイされる

サンドボックスは「エージェントが触れるリソースの集合」を制御しますが、Permission Boundary は「触れたリソースに対して何をしていいか」を制御します。両者は補完関係にあり、片方だけでは本番事故を防ぎきれません。

私が好むのは「サンドボックスで触れる対象を絞り、Permission Boundary で操作の種類を絞る」という二段構えです。これは AWS の SCP と IAM Policy の関係と同じ考え方で、防御層が独立している点が肝心です。

4階層の Permission Boundary モデル

Permission Boundary を設計するときは、操作を 4 つの階層に分けて考えると整理しやすくなります。

  • Tier 0: Read-only(読み取り専用) — SELECT・GET・list 系。ログを残すだけで自由に許可
  • Tier 1: Sandbox Write(隔離環境への書き込み) — テスト DB・ステージング S3・PR ブランチへの push。自動承認可
  • Tier 2: Production Write(本番への書き込み) — 本番 DB の UPDATE、本番デプロイ、課金 API(Stripe など)。人間承認必須
  • Tier 3: Destructive(破壊的操作) — DROP TABLE、DELETE without WHERE、ロールバック、退会処理。人間承認 + 二要素確認必須

この分類を Antigravity のタスク定義ファイル(.antigravity/tasks/*.yaml)にメタデータとして埋め込み、ランタイムで強制します。エージェント側のプロンプトに「破壊的操作はしないでください」と書くだけでは絶対に守られないので、外側から強制することが肝心です。

// src/permission-boundary/tier.ts
// 各操作の Tier を定義する型
export type PermissionTier = 0 | 1 | 2 | 3;
 
export interface AgentOperation {
  resource: string;          // 例: "db:users", "s3:bucket-prod-uploads"
  action: string;            // 例: "select", "update", "delete", "deploy"
  tier: PermissionTier;
  reason: string;            // エージェントが提示する根拠(監査ログ用)
}
 
// Tier 判定: 「リソース × 操作」のマトリクスを単一箇所で定義
export function classifyOperation(resource: string, action: string): PermissionTier {
  // Production resources
  if (resource.startsWith('db:prod:') || resource.startsWith('s3:bucket-prod-')) {
    if (['drop', 'truncate', 'delete-bucket'].includes(action)) return 3;
    if (['update', 'insert', 'delete', 'deploy'].includes(action)) return 2;
    return 0;
  }
  // Staging
  if (resource.startsWith('db:staging:') || resource.startsWith('s3:bucket-staging-')) {
    return action === 'select' ? 0 : 1;
  }
  // 未知のリソースはデフォルトで Tier 3 にして deny by default
  return 3;
}

ポイントは最後の「未知のリソースは Tier 3」というルールです。私はこれを feedback_deny_by_default.md として運用ルールに固定しています。新しいリソースを足したときに分類を忘れても、勝手に高権限で動かない設計にしておくのが安全です。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
書き込み操作を4階層に分類し、外側から強制する Permission Boundary の実装パターン
ドライラン・SQLハッシュ照合・逆操作SQL・監査ログで「巻き戻せる本番書き込み」を作る具体コード
境界そのものをCIでテストし、エージェント群が増えても破綻させない中央ポリシー・信頼度スコア運用
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-04-22
Antigravity で実装するプロンプトインジェクション防御 — LLMアプリの本番運用セキュリティ実装ガイド
LLMアプリの本番運用で避けて通れないプロンプトインジェクション対策を、Antigravityで動く実装コード付きで体系化。直接・間接・多段攻撃への多層防御を一本の記事で完結させます。
Agents & Manager2026-07-05
エージェント開発スタックの『既知の正常』を1枚のロックファイルで守る — 可動部が同時に動く時代の変更予算設計
IDEビルド・CLI・モデル・依存が同時に動くと、回帰の原因が特定できなくなります。既知の正常を1枚のロックファイルに固定し、一度に動かす軸を絞る変更予算の設計を、実装コードと運用ログで整理しました。
Agents & Manager2026-06-28
処理させる記事の本文が、そのままエージェントへの指示になっていた話
Antigravity CLI で無人のコンテンツ整形パイプラインを回していると、処理対象ファイルの本文に紛れた指示文がエージェントの動作を乗っ取ります。指示チャネルとデータチャネルを構造的に分離し、出力スコープの受け入れゲートで逸脱を弾く設計をまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →