この記事は、著者たち自身の経験から始まる。Thoughtworks の Global Marketing 部門にある彼らの AI アプリケーションチームは、「シチズンビルダー」——AI を使って構築する非技術系のユーザー——が Gemini、Replit AI、Claude で作った動画を組み立てるプロトタイプをスケールさせるよう依頼された。AI は 2 度にわたり、重大なセキュリティ上の影響を持つ方法を提案し、どちらのときも、それに気づけたのは人間が適切な質問をしたからだった。このことから著者たちは、エンタープライズグレードのガードレールのない バイブコーディング は組織が見過ごすことのできないリスクをもたらし、AI エージェントに安全であれと伝えることは、安全であることを強制することと同じではないと論じる。
彼らの答えは、最初のプロンプトからエージェントに技術的なセキュリティルールをコンテキストとして与え、その出力を開発ワークフロー内の決定論的なチェックによって検証することである——これは ハーネスエンジニアリング とその ガイドとセンサー モデルを通じて位置づけられている——。加えて、安全な道を簡単な道にするための習慣と組織的な変化も提案している。
要点
- 1 つ目のインシデントでは、AI はストレージバケットを公開にすること、あるいはクラウドのファイルストレージを「リンクを知っている全員」に設定することを勧め、どの会社でもやっていることだとそれを正当化した。きっぱりと拒否して初めて、安全な代替案が出てきた。2 つ目では、サービスアカウントに Access Token Creator ロールが付与されたが、これはタスクに必要な範囲をはるかに超えるアクセス権であり、チームはコードを実行する前にそれに気づいた。
- 著者たちの重要な洞察は、AI ツールはしばしば最も抵抗の少ない道を提案するが、それが常に安全な道とは限らない、というものである。人間の判断は依然として不可欠だが、それを唯一の統制手段にすべきではない。
- プロンプトは上書きされたり、誤解されたり、無視されたりしうる。そのため、重要な制約は、開発ライフサイクルのどこかで交渉の余地のないルールとして明文化されなければならない——プロンプトは提案にすぎず、ビルドツールの閾値こそがゲートである。
- 記事が推奨する短期的な習慣は、組織のセキュリティガイドラインを Claude、Cursor、Replit といったツールの「ルール」としてすべてのセッションに与えること、AI が提案するすべてのパーミッションを疑うこと、そして AI に攻撃者を演じさせ、作ったばかりのものにペネトレーションテストを行わせることである。
- 中期的には、チームはすべての AI コーディングセッションに読み込まれる セキュリティコンテキストファイル と、チームが使う言語、クラウドプラットフォーム、AI コーディングツールに関する新しい CVE、プラットフォームのアドバイザリー、セキュリティ告知を要約する、自動化された日次のセキュリティインテリジェンスフィードを構築した。
- 長期的には、著者たちはプロンプトからパイプラインへの移行を推奨する——セキュリティスキャナーのような計算的センサーが反応したら、エージェント的ループがモデルに、合格するまで自己修正を強いるべきである——。あわせて、セキュア・バイ・デフォルトのテンプレートと、事業部門、エンジニアリング、セキュリティが共同で構築する共有のスターターハーネスも推奨している。
- 記事は、リスクの大きさについて、第三者による 2026 年のレポートから引いた業界の数字を挙げている。その中には、AI が生成したコードの 25% に脆弱性が確認されていること、そしてエンタープライズの侵害の 5 件に 1 件が今や AI 生成コードによって引き起こされていることが含まれる。
背景
これらの推奨は、主に著者たち自身の 2 件のニアミスのインシデントと、その結果として生まれたプラットフォームに基づいている。このプラットフォームはハッカソンの期間中に 150 人のユーザーに展開されたと報告されている。統計は、記事が引用するレポートから取られた二次的なものである。記事はエンジニアに対してだけでなく、マーケティングのような事業部門にも向けられており、軽量な社内プロトタイプであっても ISO 27001 のようなエンタープライズのセキュリティ標準を満たさなければならないこと、そしてセキュリティコンテキストファイルもセキュリティインテリジェンスフィードも、導入にエンジニアリングのバックグラウンドを必要としないことを論じている。