Max Turner 氏は、Red Sentryのサイバーセキュリティリーダーとして、複雑なセキュリティ上の課題を明確かつ実用的な知見へと変換することに注力しています。彼は、ペネトレーションテスト、マーケティング、営業、エンジニア、そして経営陣と密接に連携し、組織全体での知識共有とキャリア成長の促進に取り組んでいます。
彼の経歴は多彩で、伐採業や教師、窓拭き、物流コーディネーターなど多岐にわたります。IT業界でのキャリアはネットワーク管理者からスタートしましたが、その後サイバーセキュリティの魅力に目覚め、ペネトレーションテストの分野へと転身しました。天性のリーダーシップを備えた彼は、常に「ソリューション（解決策）第一」の考え方を貫き、行く先々でポジティブなコミュニティを形成・育成することで、リーダーとしての地位を築いてきました。
技術的な深みを実社会でのインパクトへとつなげる能力に定評があるマックスは、クライアントへのアドバイス、チーム間のコラボレーション、業界イベントでの登壇などを通じて、技術職・非技術職の両方の聴衆と向き合っています。確かな技術的知識、好奇心、そして親しみやすさを兼ね備えた彼は、高度に専門的な技術現場とビジネス側のギャップを埋める存在です。また、数年間にわたる教師としての経験から、サイバーセキュリティを単なる技術的な詳細に留めず、実用的で分かりやすく、かつ意義のあるものとして伝えることを信条としています。
アメリカ出身で、2015年からは日本を拠点に活動しています。新しい場所を探索するのが大好きで、どこへ行っても志を同じくする友人を見つけるのが得意です。プライベートでは3児の父であり、夫でもあります。ランニング、カジュアルなゲーム、そして熱心なロッククライミングを趣味としています。ストーリーテリング（物語を伝えること）と時折混じる「おやじギャグ」こそが、どんなに複雑なトピックでも、誰にとっても興味深く親しみやすいものに変えられると彼は信じています。
[Linkedin – Max](https://www.linkedin.com/in/max-turner-2495ba68/)
**なぜ、AIを使ってコードを書いていると知ると、ハッカーは色めき立つのでしょうか？**
先日、私たちのチームはある事例を耳にしました。AIコーディング・エージェントが、企業の全本番データベースとバックアップを、わずか数秒で消去してしまったという話です。これは「AIが暴走した」という類の話ではなく、マシンの処理速度で発生した「アクセス制御の不備」によるものです。私たちは、これと同様のパターンが実際のアプリケーションで頻繁に見られるようになっているのを目の当たりにしています。
この講演では、こうしたパターンがなぜホワイトハッカーである私たちのチームを興奮させるのか、そしてなぜ悪意のあるハッカーたちも同様にこれらに期待を寄せているのかについてお話しします。
先述したコード消去エージェントのような事態は、実装や設計が浅く、おそらく厳しい納期に追われてリリースされたことを示唆しています。これは決して新しい現象ではありません。しかし今回異なるのは、アプリケーションの設計者がコードを一行ずつ積み上げて作る必要がなかったという点です。彼らは、堅牢な製品が出来上がるまで調査し、テストし、失敗し、それを繰り返すというプロセスを経る必要がありませんでした。
完成した製品は確かに動きますが、そのソースコード・レベルで内容をしっかりと把握しているエンジニアは、いたとしてもごくわずかでしょう。つまり、「コードを理解するのにかかる時間よりも早く、コードをリリースできてしまった」のです。
この講演では、AIを活用して構築されたアプリケーションをテストする中で、私たちのチームが発見した事例をいくつか紹介します。これらのアプリは、AIによるコーディング支援を受けたもの、AI機能を統合したもの、あるいは完全にバイブ・コーディングで作られたものです。
アクセス制御の不備（Broken Access Control）は、私たちが長年レポートに記載してきた問題ですが、AIで構築されたアプリでは特によく見かけます。これにはいくつかのパターンがあります。最近、SupabaseというBaaSプラットフォームを利用したアプリを調査しました。このバイブ・コーディングされたアプリは、ブラウザで低権限の「anon」キーを使用する代わりに、フロントエンドのJavaScript内に「service」ロール（管理者権限）キーを埋め込んで初期化していました。このキーがあれば、バックエンドでやりたい放題できてしまいます。任意のユーザーやテナントになりすまして操作したり、UIには決して表示されないはずのデータを見たりすることも可能です。これは重大な問題です。
もう一つよく見られるのが、APIキーの露出です。最近テストしたAI構築のアプリでは、GeminiのAPIキーが漏洩していました。そのキーを使って、クライアントの内部AIモデルへのアクセスに成功しました。内部ファイルを閲覧できただけでなく、この脆弱性を悪用すれば、使用されたすべてのトークン費用がクライアントに請求されるため、深刻な経済的打撃を与えることも可能でした。
また、LLMやMCP（Model Context Protocol）と直接連携しているアプリケーションもテストしています。私たちのチームは、こうした環境でかなり攻めた調査を行うことができます。つい最近も、Sonnet 4.6モデルを搭載した環境をテストしました。テスターはプロンプト・インジェクションを仕掛け、code_execツールを使用して、モデル自身のFirecrackerマイクロVM内部で診断を実行させました。そこでCLIを持つClaudeユーザーを発見しましたが、ツールは公開されていませんでした。そこでチームは、アプリケーション独自のMCPをClaude CLIのラッパーとして使い、フルシステムアクセス権限で実行させることに成功したのです。
これらは、冒頭で触れた9秒間でのデータベース消失を含め、APIの過剰な露出や過剰な権限を持つシステムの典型的な例です。このほか、IDOR（不適切なオブジェクト参照による認証不備）や、レート制限・ログ記録といったガードレールの欠如についても掘り下げていきます。
ここで繰り返される共通のテーマは、「私たちが攻略しているのはAIそのものではなく、その背後にあるアクセス権限や思い込み（前提条件）である」ということです。
