あなたのプラットフォームチームにはエージェントポリシーが必要でした — 昨日

3 月 3 日、攻撃者は Xygeni GitHub Action の変数が置換可能なタグを中毒させ、攻撃を行いました。xygeni/xygeni-action@v5 を参照するすべての CI ランナーは、静かに C2 サーバーへの逆シェルを実行するようになり、曝露期間は 1 週間続き、137 つ以上のリポジトリに影響が出ました。 原因は画期的なものでもありませんでした。過剰な権限が設定された GitHub App のプライベートキーと、維持管理者の個人アクセントークンの両方が侵害されました。これにより、攻撃者は人間がレビューする必要なく PR を作成し、タグを移動させることができました。 これは、統制なく自動化されたアクターが動くことのできる何であるかというものです。そして、これがさらに悪化しつつあります。 あなたのプラットフォームチームはすでに開発者、サービスアカウント、CI ボットのために身なりを管理していますが、AI エージェントは全く異なるカテゴリーです。 開発者はドキュメントを読み、考え、PR を開きます。サービスアカウントは固定したスクリプトを実行します。一方、AI エージェントは中間的な何かを行います——それは何をすべきかを推理し、その後実行することです。それはインフラを生成したり、構成を変更したり、API を呼び出したり、あるいは多くのツールのチェーンを実行したりする可能性があります。侵害された、または不正確に設定されたエージェントの爆発的半径は、壊れた cronジョブよりも悪意ある管理者に近いものです。 しかし、多くの組織はエージェントを他のどのサービスアカウントも同じように扱っています。同じ IAM ロール、同じ広範な権限、同じランタイムモニタリングの欠如です。 このデータはそれを裏付けます。2026 年に行われた Gravitee の報告によると、80.9% の技術チームがエージェントをアクティブなテストまたはプロダクション環境に押し進めましたが、80.9% の技術チームがエージェントをアクティブなテストまたはプロダクション環境に押し進めましたが、14.4% のみがフルセキュリティと IT 承認付きで実行されました。そしてここはトリビアです：82% の経営幹部は、既存のポリシーが不正なエージェントアクションをカバーしていることを自信を持っており、21% のみが、エージェントが何にアクセスしているか、どのようなツールを呼び出しているか、あるいはどのようなデータを触れているかを把握しています。 それはギャップではありません。それは峡谷です。 エージェントポリシーは、法律が署名する PDF ではありません。それは、プラットフォームチームがゴールデンパス（理想状態の経路）に組み込む強制制約のセットです。これはどのように意味するか： 身なりと RBAC すべてのエージェントは専用の身なり——共有サービスアカウントでも、開発者の認証でもありません——を所有します。各身なりは、明確にスコープされた権限を持つ役割に対応します。エージェントが Terraform を書き込めば、それらを管理する特定のモジュールへの書き込み権限を得、それ以上のものはないはずです。 これは直感に反します。実際には、多くのチームは、ローカル開発に使用する同じ広範な IAM ロールをエージェントに渡す傾向があり、これは船出が速いためです。 ランタイム境界 静的な権限だけでは十分ではありません。エージェントはランタイムで判断を下します、そしてその判断にはガードレールが必要です： API 呼び出しとリソース作成に対するレート制限 エージェントが実行できるツールとエンドポイントのホワイトリスト 実行ごとにコストの天井（曖昧なプロンプトが 50 つの GPU インスタンスを起動させたエージェントは高価な過ちです） 破壊的操作（リソースの削除、セキュリティグループの変更、メインへのプッシュ）を必須の人間による介入とする 監査と観測 すべてのエージェントアクションはトレースを生成する必要があります。ログだけでなく、推論チェーン、実行されたツール、アクセスされたデータ、そして結果をキャプチャする構造化されたトレースです。何かおかしいことが起きた時（それは起きるでしょう）、あなたはエージェントが何をしたのか、なぜそのようにしたのかを正確に再構築する必要があります。 CNCF の 2026 年の予報はこれをよく表現しています：企業の自律化への移行は、ゴールデンパス、ガードレール、セーフティネット、そして手動レビューワーフローの 4 つの制御メカニズムによって定義されるでしょう。すべてエージェントに適用されます。 サプライチェーン検証 Xygeni の攻撃は、自動化されたアクターに対するサプライチェーン攻撃でした。あなたのエージェントポリシーは、エージェント自身の依存関係もカバーする必要があります：固定されたバージョン（変数が置換可能なタグではない）、シグネイチャー検証、およびエージェントが消費するどのアクションやツールのための provenance チェックです。もしあなたの CI エージェントが some-action@v3 を参照しているなら、あなたはタグが移動されていないことを信頼しています。代わりにコミットの SHA にピン留めしてください。 あなたは全てを煮詰める必要はありません。プロダクションにあるすべてのエージェントに対して 1 つの質問に答えるところから始めましょう：現在の権限を持って、このエージェントは何を最悪の結果として行うことができますか？ 答えがあなたを不快にさせるなら、あなたは最初のポリシー項目を見つけたことになります。 そこから： エージェントのインベントリを作成してください。

On March 3rd, an attacker compromised the Xygeni GitHub Action by poisoning a mutable tag. Every CI runner referencing xygeni/xygeni-action@v5 quietly started executing a reverse shell to a C2 server. The exposure window lasted a week. 137+ repositories were affected. The root cause wasn't exotic. A GitHub App private key with overly broad permissions got compromised. Combined with a maintainer's personal access token, the attacker could create a PR and move the tag — no human review required. This is what happens when automated actors run without governance. And it's about to get much worse. Your platform team already manages identities for developers, service accounts, and CI bots. But AI agents are a fundamentally different category. A developer reads docs, thinks, and opens a PR. A service account runs a fixed script. An AI agent does something in between — it reasons about what to do, then acts. It might create infrastructure, modify configurations, call APIs, or chain together a dozen tools. The blast radius of a compromised or misconfigured agent is closer to a rogue admin than a broken cron job. Yet most organizations treat agents like any other service account. Same IAM roles. Same broad permissions. Same lack of runtime monitoring. The numbers back this up. A 2026 Gravitee report found that 80.9% of technical teams have pushed agents into active testing or production, but only 14.4% went live with full security and IT approval. And here's the kicker: 82% of executives feel confident their existing policies cover unauthorized agent actions, while only 21% have actual visibility into what their agents access, which tools they call, or what data they touch. That's not a gap. That's a canyon. An agent policy isn't a PDF that legal signs off on. It's a set of enforced constraints that your platform team builds into the golden path. Here's what that means in practice: Identity and RBAC Every agent gets a dedicated identity — not a shared service account, not a developer's credentials. Each identity maps to a role with explicitly scoped permissions. If an agent writes Terraform, it gets write access to the specific modules it manages and nothing else. This sounds obvious. In practice, most teams hand agents the same broad IAM role they use for local development because it's faster to ship. Runtime Boundaries Static permissions aren't enough. Agents make decisions at runtime, and those decisions need guardrails: Rate limits on API calls and resource creation Allowlists for which tools and endpoints an agent can invoke Cost ceilings per execution (an agent that spins up 50 GPU instances because the prompt was ambiguous is an expensive mistake) Mandatory human-in-the-loop for destructive operations — deleting resources, modifying security groups, pushing to main Audit and Observability Every agent action should produce a trace. Not just logs — structured traces that capture the reasoning chain, the tools invoked, the data accessed, and the outcome. When something goes wrong (and it will), you need to reconstruct exactly what the agent did and why. The CNCF's 2026 forecast frames this well: the enterprise shift to autonomy will be defined by four control mechanisms — golden paths, guardrails, safety nets, and manual review workflows. All four apply to agents. Supply Chain Verification The Xygeni attack was a supply chain attack on an automated actor. Your agent policy needs to cover the agents' own dependencies: pinned versions (not mutable tags), signature verification, and provenance checks for any action or tool an agent consumes. If your CI agent references some-action@v3, you're trusting that the tag hasn't been moved. Pin to a commit SHA instead. You don't need to boil the ocean. Start by answering one question for every agent in production: what's the worst thing this agent could do with its current permissions? If the answer makes you uncomfortable, you've found your first policy item. From there: Inventory your agents. You can't govern what you can't see. OneTrust, CloudEagle, and similar platforms now offer agent discovery — continuously scanning for AI agents, their ownership, integrations, and data access. Scope permissions to the task. Apply least-privilege like you would for any identity. An agent that summarizes Jira tickets doesn't need write access to your infrastructure. Add runtime guardrails before production. Galileo's open-source Agent Control and Palo Alto's agentic governance tools are both worth evaluating. The pattern is the same: intercept agent actions at runtime, check them against policy, and block or escalate violations. Pin your dependencies. Mutable tags are a liability. Every action, plugin, or tool your agents consume should be pinned to an immutable reference. Build the audit trail now. Retroactively reconstructing what an agent did is painful. Instrument from day one. This Is a Platform Problem Some teams try to solve agent governance at the application layer — each team building their own guardrails. That doesn't scale, and it doesn't produce consistent policy enforcement. This is a platform engineering problem. The same team that builds your internal developer platform, manages your golden paths, and enforces your deployment policies should own agent governance. They have the infrastructure context. They have the policy enforcement mechanisms. And they're already thinking about developer experience, which matters because overly restrictive agent policies that slow teams down will just get bypassed. The Xygeni attack was a preview. The attack surface for AI agents in CI/CD, infrastructure management, and code generation is growing fast. Your platform team needs an agent policy — not next quarter, not after the first incident. Yesterday.