要旨

「このバグの直し方、ChatGPTに聞いてみよう」——2026年現在、これは珍しい光景ではありません。JetBrainsの2025年10月調査では、85%近くの開発者がすでにAIコーディングツールを日常業務で使用しています[1]。

しかし、この習慣が「会社を破滅させかけた話」になっている事例が急増しています。2023年にSamsungでは、3人のエンジニアが3週間以内にソースコード・社内会議録・チップ測定データをChatGPTに貼り付けていたことが発覚し、全社ChatGPT利用禁止に至りました[2]。2026年の調査では、従業員のChatGPT入力のうち機密データを含む割合が34.8%（2023年の11%から3倍増）に達しています[3]。

本記事では、開発者がAIツールを使う際に「やってはいけない」3つの行為を、技術的な理由と実際の対策とともに解説します。3つとは——①機密データ・個人情報の無断投入、②AI生成コードの無検証マージ、③フォールバック経路としての無承認AIツール活用です。

注意事項：本記事は教育目的のセキュリティ情報共有を目的としています。

記事本文

はじめに——「AIへのコード貼り付け」が普通になった世界のリスク

開発者がChatGPTやGitHub CopilotにコードやログやSQLを貼り付ける理由はシンプルです。速い・賢い・無料（または安い）。しかし、そこには「誰もあなたに教えてくれていない」3つのリスクが潜んでいます。

AIへのコード貼り付けの典型シナリオ：

朝9時
  開発者: 「このエラー、なんで出るんだろう」
  → 本番ログ（顧客IDとメールアドレスが含まれる）をコピー
  → ChatGPTに貼り付け「このエラーの原因を教えて」

午後2時
  開発者: 「認証モジュール、どう書けばいいかな」
  → GitHub Copilotが提案するコードをそのまま採用
  → レビューなしでメインブランチにマージ

夕方5時
  開発者: 「このDB設計レビューしてほしい」
  → 社外秘の顧客データベーススキーマをChatGPTに共有

3つのやってはいけないこと、すべてやっています。

やってはいけない①：機密データ・個人情報をAIに無断投入する

なぜこれが問題なのか

最も重要な前提認識から始めます。

ChatGPT（Free/Plus/Teamプラン）はデフォルトでユーザーの入力を学習データとして使用します。

"ChatGPT Free, Plus, and Team train on your data by default. Only Enterprise and the API come with Zero Data Retention (ZDR) by default. Most 'shadow AI' incidents happen on personal Plus accounts your IT team never authorized."
— Strac.io, "ChatGPT Security Risks in Enterprise: 2026 Guide" [2]
https://www.strac.io/blog/chatgpt-security-risk-and-concerns-in-enterprise

"The real risk isn't the model — it's your employees. Pasting PII, source code, customer records, and credentials into ChatGPT is the #1 cause of ChatGPT data leaks in enterprise. OpenAI protects the pipes, not the content."
— Strac.io [2]
https://www.strac.io/blog/chatgpt-security-risk-and-concerns-in-enterprise

TLS 1.2+・AES-256・SOC 2 Type IIなど通信経路の暗号化は実装されています。しかしそれはあなたの入力内容を守るものではありません——暗号化はOpenAIのサーバーに届くまでの「道中」を守るだけで、サーバーに届いた入力の取り扱いはOpenAIのポリシー次第です。

規模の現実

指標	数値	出典
AIツール経由でのシークレット漏洩（2024年）	2,380万件（前年比25%増）	IntuitionLabs [4]
ChatGPT入力のうち機密情報を含む割合（2023年）	11%	Cyberhaven / Strac [2]
ChatGPT入力のうち機密情報を含む割合（2026年）	34.8%（3倍増）	aibuzz.blog [3]
20%超のファイルアップロードに機密情報	20%	Harmonic Security 2025 [5]
Samsung発覚から全社禁止までの期間	20日以内	複数メディア報告 [2]

やってしまいがちな「危険な貼り付け」パターン

# ❌ NGパターン1: 本番ログをそのまま貼り付け
# ChatGPTへの質問文：
"""
以下のエラーログを解析してください：

[2026-07-16 09:30:15] ERROR: Database query failed
User: tanaka.taro@company.co.jp
Customer ID: CUST-00123456
Query: SELECT * FROM orders WHERE customer_id = 'CUST-00123456'
Error: Connection timeout to prod-db-tokyo-01.internal:5432
Stack: at db.connect() [/app/services/order.ts:142]
"""
# 問題：顧客のメールアドレス・ID・内部DBのホスト名がすべて露出

# ✅ 安全なパターン: 匿名化・一般化してから質問
"""
以下のエラーを解析してください：

エラー: データベース接続タイムアウト
スタック: DBサービスの接続メソッド
発生条件: 特定のクエリ実行時

このタイムアウトエラーの一般的な原因と対処法を教えてください。
"""

# ❌ NGパターン2: APIキーやシークレットが混入したコードを貼り付け
code_with_secret = """
import stripe

stripe.api_key = "sk_live_51H9xxxxxxxxxxxxxxxxxxxxxxxxxxx"

def charge_customer(amount, token):
    charge = stripe.Charge.create(
        amount=amount,
        currency="jpy",
        source=token,
    )
    return charge
"""
# ChatGPTに「このコードのエラーを直して」と送ったら
# 本番Stripeキーが学習データに...

# ✅ 安全なパターン: シークレットを除去してから質問
safe_code = """
import stripe
import os

stripe.api_key = os.environ.get("STRIPE_SECRET_KEY")

def charge_customer(amount, token):
    charge = stripe.Charge.create(
        amount=amount,
        currency="jpy",
        source=token,
    )
    return charge
"""
# 実際のキーは含まれていないので安全

# ❌ NGパターン3: 顧客データを含むSQLの貼り付け
dangerous_query = """
以下のSQLを最適化してください：

SELECT u.name, u.email, u.phone, o.product_name, o.amount
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.name IN ('山田太郎', '佐藤花子', '田中一郎')
AND o.amount > 100000
ORDER BY o.created_at DESC;

現在の実行時間: 45秒
"""
# 問題：実在の顧客名が含まれている

# ✅ 安全なパターン: 構造だけ共有
safe_query = """
以下のSQLを最適化してください（カラム名・テーブル構造は架空のものです）：

SELECT u.name, u.email, u.phone, o.product_name, o.amount
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.name IN ('UserA', 'UserB', 'UserC')
AND o.amount > [threshold]
ORDER BY o.created_at DESC;

現在の実行時間: 45秒
"""

プランごとのデータ取り扱いの違いを把握する

ChatGPT プランごとのデータポリシー（2026年7月時点）：

Free / Plus / Pro:
  ├── デフォルト: 入力が学習に使用される
  ├── オプトアウト: Settings > Data Controls > 学習オフ
  └── オフにしても30日間はサーバーに保持

Team:
  ├── デフォルト: 学習に使用される（要確認）
  └── 管理者が学習をオフにできる

Enterprise:
  ├── デフォルト: 学習に使用されない（ZDR）
  ├── 会話は30日で削除
  └── ただしフィードバック（👍👎）で学習対象になる可能性あり

API:
  ├── デフォルト: 学習に使用されない（ZDR）
  └── 最もセキュアな業務利用形態

※ Microsoft Copilot (M365):
  ├── 企業テナント内のデータのみ参照
  ├── ChatGPTとは異なりデータが社外に出ない設計
  └── ただし「Copilot が閲覧できるファイル範囲」の過共有問題がある

"ChatGPT operates outside your compliance framework unless you build controls from scratch. Copilot has built-in enterprise management; ChatGPT is a wild card without intentional lockdown."
— Concentric AI, "ChatGPT Security Risks in 2026" [6]
https://concentric.ai/chatgpt-security-risks-in-2026-a-guide-to-risks-your-team-might-be-missing/

データ分類に基づく「AIに投入して良いもの・悪いもの」一覧

AIへの入力 可否チェックリスト：

✅ 投入してよいもの
  ・アルゴリズムの質問（架空のデータを使った例）
  ・一般的なコードパターン・設計相談
  ・公開されているAPIのドキュメント解説
  ・オープンソースコードの解説
  ・架空データを使ったSQL最適化の相談

⚠️  匿名化・一般化すれば投入可
  ・エラーメッセージ（ホスト名・IP・ユーザー名を除去）
  ・コードのロジック（シークレット・接続情報を除去）
  ・データベーススキーマ（固有名詞を汎用名に置換）

❌ 絶対に投入してはいけないもの
  ・顧客の個人情報（氏名・メール・電話・住所）
  ・認証情報（APIキー・パスワード・トークン・証明書）
  ・未公開の製品情報・ロードマップ
  ・財務データ・M&A情報
  ・本番環境のホスト名・IP・インフラ構成
  ・社外秘・機密指定のドキュメント
  ・医療情報・個人番号・クレジットカード番号

やってはいけない②：AI生成コードを「レビューなし」でそのままマージする

AIが生成したコードの45%に脆弱性がある

"According to the Veracode 2025 GenAI Code Security Report, which analyzed code produced by over 100 LLM models across 80 real programming tasks, generative AI introduces security vulnerabilities in 45% of cases. For Java — the most popular enterprise language — this rate exceeds 70%."
— ARDURA Consulting, "AI Generated Code Security 2026" [7]
https://ardura.consulting/blog/ai-generated-code-why-45-percent-copilot-code-contains-security-vulnerabilities/

"78% of AI-generated code contains at least one exploitable security vulnerability that traditional security scanning tools fail to detect."
— Blue Radius, "GitHub Copilot Security Review 2026" [8]
https://blueradius.io/github-copilot-security-review-2025

これらの数字は「AIが意地悪をしている」わけではありません。構造的な問題があります。

なぜAIは脆弱なコードを生成するのか：

"The vicious cycle is now automated: insecure example code gets copied into production systems, those systems become training data for LLMs, and the models learn to generate similar insecure code. Each iteration reinforces rather than corrects these patterns."
— Medium, "AI is writing your code. Who's checking for vulnerabilities?" [9]
https://medium.com/@michael.hannecke/ai-is-writing-your-code-whos-checking-for-vulnerabilities-30377e98e0f2

AIが脆弱なコードを生成するメカニズム：

インターネット上のコード（訓練データ）
  ├── 古いベストプラクティスで書かれたコード
  ├── セキュリティパッチ適用前のコード
  ├── Stack Overflow の「とりあえず動く」回答
  └── セキュリティが考慮されていないチュートリアル
          ↓
      AIが学習
          ↓
      「よく見かけるパターン」として提案
          ↓
  開発者がそのまま採用 → 本番環境へ

悪循環：
AIが生成したコードがGitHubに公開
 → 次世代AIの訓練データに
 → 脆弱なパターンが「正常」として強化される

AIが生成しやすい脆弱なコードの実例

# ❌ AIが提案しがちな脆弱なパターン①: SQLインジェクション（CWE-89）

# AIへの質問: 「ユーザー名でユーザーを検索するPython関数を書いて」
# AIの回答（問題あり）:
def search_user(username: str) -> dict:
    query = f"SELECT * FROM users WHERE username = '{username}'"
    return db.execute(query)

# 問題: f文字列でSQLを組み立てている
# 攻撃: username = "' OR '1'='1" → 全ユーザーが返る
# username = "'; DROP TABLE users;--" → テーブル削除

# ✅ 安全なパターン: パラメータバインディング
def search_user_safe(username: str) -> dict:
    query = "SELECT * FROM users WHERE username = %s"
    return db.execute(query, (username,))
    # AIに「パラメータバインディングを使って」と指示すれば
    # 安全なコードを提案する可能性が高まる

# ❌ AIが提案しがちな脆弱なパターン②: 不十分な乱数（CWE-330）

# AIへの質問: 「セッションIDを生成する関数を書いて」
# AIの回答（問題あり）:
import random
import string

def generate_session_id() -> str:
    chars = string.ascii_letters + string.digits
    return ''.join(random.choice(chars) for _ in range(32))

# 問題: random モジュールは暗号学的に安全ではない
# 予測可能なシードから攻撃者がセッションIDを推測できる

# ✅ 安全なパターン: 暗号学的に安全な乱数
import secrets
import string

def generate_session_id_safe() -> str:
    return secrets.token_hex(32)  # または secrets.token_urlsafe(32)

// ❌ AIが提案しがちな脆弱なパターン③: XSS（CWE-79）

// AIへの質問: 「ユーザーのコメントをページに表示するJSを書いて」
// AIの回答（問題あり）:
function displayComment(comment) {
  document.getElementById('comment-area').innerHTML = comment;
  // innerHTML を使うと、comment に <script> が含まれていたら実行される
}

// ✅ 安全なパターン: textContent を使う or DOMPurify でサニタイズ
function displayCommentSafe(comment) {
  document.getElementById('comment-area').textContent = comment;
  // または
  // document.getElementById('comment-area').innerHTML = DOMPurify.sanitize(comment);
}

# ❌ AIが提案しがちな脆弱なパターン④: ハードコードされたシークレット

# AIへの質問: 「AWS S3にファイルをアップロードする関数を書いて」
# AIが（稀に）提案する問題のあるパターン:
import boto3

def upload_to_s3(file_path: str, bucket: str) -> bool:
    s3 = boto3.client(
        's3',
        aws_access_key_id='AKIAIOSFODNN7EXAMPLE',  # ← ハードコード
        aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
    )
    s3.upload_file(file_path, bucket, file_path)
    return True

# ✅ 安全なパターン:
import boto3
import os

def upload_to_s3_safe(file_path: str, bucket: str) -> bool:
    # IAMロール or 環境変数から自動取得（boto3のデフォルト動作）
    s3 = boto3.client('s3')
    s3.upload_file(file_path, bucket, file_path)
    return True

「スロップスクワッティング」——存在しないパッケージ名を攻撃者が先取りする

"Approximately 20% of AI-generated code samples reference packages that do not exist — a predictable hallucination pattern that attackers exploit through 'slopsquatting,' registering the hallucinated names as malicious packages before developers install them."
— Cloud Security Alliance, "Vibe Coding's Security Debt: The AI-Generated CVE Surge" [10]
https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/

# スロップスクワッティング攻撃の仕組み

# 1. AIが存在しないパッケージを提案する（ハルシネーション）
# AIの回答: 「pip install django-secure-auth を使ってください」
# 実際: django-secure-auth というパッケージは存在しない

# 2. 攻撃者がその名前でパッケージを登録
# pip install django-secure-auth
# → 攻撃者が作った悪意あるパッケージがインストールされる

# 3. インストール時にマルウェアが実行される
# setup.py の install_requires や postinstall スクリプトで
# バックドアや認証情報窃取スクリプトが動く

# 対策: パッケージ名を必ず公式ドキュメントで確認してからインストール
# pip search や PyPI.org で実在を確認
# requirements.txt にはバージョンをピン留め（== x.y.z）

# 確認コマンド
pip index versions django-secure-auth  # パッケージの存在確認

AI生成コードを安全に使うためのレビューチェックリスト

AI生成コードのセキュリティレビューチェックリスト：

入力検証:
  ✅ ユーザー入力がそのままSQLに組み込まれていないか
  ✅ パラメータバインディングを使っているか
  ✅ 入力の型・長さ・形式を検証しているか

認証・認可:
  ✅ ハードコードされたシークレット・パスワードがないか
  ✅ APIキー・トークンが環境変数から取得されているか
  ✅ 認可チェック（権限確認）が実装されているか

暗号化:
  ✅ random モジュールではなく secrets を使っているか
  ✅ MD5・SHA1ではなくSHA-256以上を使っているか
  ✅ 非推奨の暗号アルゴリズムを使っていないか

依存関係:
  ✅ 推奨されたパッケージが実際に存在するか（PyPI/npmで確認）
  ✅ バージョンが最新（または既知の安全なバージョン）か
  ✅ 既知の脆弱性がないか（pip-audit / npm audit）

ツールによる自動検査:
  ✅ SAST ツール（Semgrep / Bandit / CodeQL）でスキャン
  ✅ gitleaks で認証情報の混入チェック
  ✅ Snyk / Dependabot で依存関係の脆弱性チェック

# 実際に使えるSASTコマンド例

# Python: Bandit でセキュリティチェック
pip install bandit
bandit -r ./src -ll  # 中・高リスクの問題のみ表示

# Python/JavaScript: Semgrep でCWEパターン検出
semgrep --config=p/owasp-top-ten .

# 全言語: gitleaks でシークレット混入チェック
gitleaks detect --source . --verbose

# 依存関係の脆弱性チェック
pip-audit                  # Python
npm audit --audit-level=moderate  # Node.js

# GitHub Actions での自動化例（PRのたびに実行）
# .github/workflows/security.yml
# → CI/CDにセキュリティスキャンを組み込む

やってはいけない③：会社の承認なしに個人アカウントのAIを業務利用する

「Copilotが入っているから他のAIツールは使わない」ルールが機能しない理由

"The U.S. House of Representatives banned congressional staff from using Copilot due to concerns about data security and the potential risk of leaking House data to unauthorized cloud services."
— Concentric AI, "Microsoft Copilot Security Concerns 2026" [11]
https://concentric.ai/too-much-access-microsoft-copilot-data-risks-explained/

会社がCopilot（M365）を導入した場合でも、従業員が個人のChatGPT Plusアカウントを「作業が遅いから」「Copilotより賢いから」という理由で使い続けるのが現実です。これがシャドーAI問題です。

シャドーAIが生まれる典型的な状況：

09:00 会社: Microsoft 365 Copilot を全社展開
      社員: 「Copilotって賢くないな...」

09:30 社員: 個人のChatGPT Plusで本番DBのスキーマを貼り付け
      「こっちの方が早い」

11:00 社員: 個人のGeminiで未公開製品ロードマップを要約
      「会議前に整理したかっただけ」

14:00 社員: 個人デバイスの Claude.ai で顧客リストを分析
      「作業効率上がるし、誰にも迷惑かけてないし」

↓

ITチームはこれらを全く把握できていない

個人アカウントChatGPTと企業向けCopilotの決定的な違い

項目	ChatGPT（個人Free/Plus）	Microsoft 365 Copilot
データの行き先	OpenAIのサーバー（社外）	企業テナント内
学習への使用	デフォルトON	なし（テナント内完結）
IT部門の可視性	❌ ゼロ	✅ ログで把握可能
コンプライアンス範囲	社外のSaaS	社内コンプライアンス内
GDPR/個人情報保護法	対応が複雑	M365の枠組みで対応
DLP（データ損失防止）ポリシー	❌ 適用不可	✅ 適用可能

Copilotにも「過共有」という固有リスクがある

"Microsoft has publicly acknowledged oversharing as one of the top Copilot rollout risks."
— RansomLeak, "AI Data Leakage" [12]
https://ransomleak.com/blog/ai-data-leakage-employees/

Copilotはユーザーがアクセスできるすべてのファイル・メール・会議録を参照できます。これは便利な反面、「アクセス制御が甘いファイル」の内容をCopilotが回答に使ってしまうリスクがあります。

# Microsoft 365 Copilot の過共有リスクを確認・対策するコマンド例

# 1. 組織全体に共有されているファイルを確認
# SharePoint Admin Center または Graph API で確認

# PowerShell例：全社共有のサイトコンテンツを確認
Connect-SPOService -Url "https://contoso-admin.sharepoint.com"
Get-SPOSite | Where-Object { $_.SharingCapability -eq "ExternalUserAndGuestSharing" }

# 2. Microsoft Purview での機密情報ラベル確認
# 「社外秘」ラベルの付いたファイルへの Copilot のアクセスを制限

# 3. Copilot の利用ログを確認（Azure AD サインインログ）
# Microsoft 365 管理センター → レポート → Copilot 使用状況

# 4. 過共有されたOneDriveファイルを特定
# Microsoft SharePoint Syntex または Purview でスキャン

組織として今すぐ実施すべきこと

AI利用ガバナンスの3層モデル：

Layer 1: 可視化（Shadow AI Discovery）
  ├── DNSログで主要AIドメインへのアクセスを検出
  │   （api.openai.com / claude.ai / gemini.google.com 等）
  ├── CASB/SWGでAIカテゴリのトラフィックをログ収集
  └── 月次でサービス別の利用量・ユーザーを把握

Layer 2: ポリシー（AI Acceptable Use Policy）
  ├── 承認済みツールのホワイトリスト化
  ├── データ分類に基づく利用制限の明文化
  │   └── 「機密区分3以上のデータはAIへの入力禁止」等
  └── 個人アカウントでの業務データ入力の明示的な禁止

Layer 3: 技術制御（Technical Enforcement）
  ├── DLPルールでAI APIエンドポイントへの
  │   機密データ送信を検知・ブロック
  ├── 社用PCでは個人ChatGPTアカウントへのログインを制限
  └── 入力前にPII・シークレットを自動スクラビングするプロキシ

3つのやってはいけないことを「やってしまった後」の対応フロー

万が一やってしまった場合の対応手順も把握しておきます。

やってしまった時の緊急対応フロー：

① 機密データをAIに入力してしまった場合：

  即時: OpenAI / Anthropic / Google のプライバシーポータルから
        当該会話の削除を申請
        https://privacy.openai.com （OpenAI）

  24時間以内:
        - 情報セキュリティ部門・上長に報告
        - 漏洩した情報の種類と範囲を特定
        - APIキー等の認証情報が含まれていた場合は即座にローテーション
        - 個人情報が含まれていた場合はプライバシー担当者に連絡
          （GDPR対象の場合は72時間以内の規制当局報告義務を確認）

  1週間以内:
        - インシデントレポートの作成
        - 再発防止策の実装
        - 影響を受けた顧客・関係者への通知（必要な場合）

② AI生成コードに脆弱性が混入した場合：

  即時: 脆弱なコードを含むリリースの影響範囲を特定

  24時間以内:
        - 影響するエンドポイント・機能を特定
        - 本番環境への影響を評価（ログ分析）
        - 修正版のホットフィックスをデプロイ

  1週間以内:
        - SAST ツールで全コードベースをスキャン
        - CI/CDへのセキュリティゲートの追加
        - チームへのセキュアコーディング研修

まとめ——「便利さ」と「安全さ」を両立させる3つの習慣

AIコーディングツールは間違いなく開発者の生産性を向上させます。禁止ではなく「安全に使う」のが現実的な答えです。

3つのやってはいけないことと対策：

#	やってはいけないこと	代わりにすること
①	機密データ・個人情報をそのまま投入	匿名化・一般化してから質問。認証情報は絶対に含めない
②	AI生成コードをレビューなしでマージ	SASTツール＋目視レビュー。パッケージ名は公式で確認
③	個人アカウントのAIで業務データを扱う	会社承認済みのEnterprise AI or Copilotのみ利用

"The security implications of LLM-generated code aren't temporary, and waiting for the technology to improve isn't a strategy. The same secure coding practices that have always mattered — input validation, output encoding, proper authentication, defense in depth — remain effective."
— Medium, "AI is writing your code. Who's checking for vulnerabilities?" [9]
https://medium.com/@michael.hannecke/ai-is-writing-your-code-whos-checking-for-vulnerabilities-30377e98e0f2

AIに聞く前の「1秒の確認」——「このデータを全世界に公開しても平気か？」。この問いかけが、会社を守る最初の防衛線です。

参考文献

[1] JetBrains. "Developer Ecosystem Survey 2025 — AI Tool Usage." October 2025.
https://www.jetbrains.com/lp/devecosystem-2025/

[2] Strac.io. "ChatGPT Security Risks in Enterprise: 2026 Guide to Data Leaks, Breaches & Prevention." April 27, 2026.
https://www.strac.io/blog/chatgpt-security-risk-and-concerns-in-enterprise

[3] aibuzz.blog. "AI Data Loss Prevention for ChatGPT and Copilots (2026)." June 5, 2026.
https://aibuzz.blog/ai-data-loss-prevention-for-chatgpt-copilots/

[4] IntuitionLabs. "AI Data Classification: What Is Safe for ChatGPT & Copilot." 2026.
https://intuitionlabs.ai/articles/ai-data-classification-chatgpt-copilot-gemini-policies

[5] IntuitionLabs. "ChatGPT Data Security: Preventing Proprietary Data Leaks." 2026.
https://intuitionlabs.ai/articles/prevent-chatgpt-proprietary-data-leaks

[6] Concentric AI. "A 2026 Guide to ChatGPT Risks." April 1, 2026.
https://concentric.ai/chatgpt-security-risks-in-2026-a-guide-to-risks-your-team-might-be-missing/

[7] ARDURA Consulting. "AI Generated Code Security 2026: Why 45% of Copilot Code Contains Security Vulnerabilities." February 27, 2026.
https://ardura.consulting/blog/ai-generated-code-why-45-percent-copilot-code-contains-security-vulnerabilities/

[8] Blue Radius. "GitHub Copilot Security Review 2026: 7 CISO Risks." 2026.
https://blueradius.io/github-copilot-security-review-2025

[9] Michael Hannecke. "AI is writing your code. Who's checking for vulnerabilities?" Medium, October 22, 2025.
https://medium.com/@michael.hannecke/ai-is-writing-your-code-whos-checking-for-vulnerabilities-30377e98e0f2

[10] Cloud Security Alliance. "Vibe Coding's Security Debt: The AI-Generated CVE Surge." May 20, 2026.
https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/

[11] Concentric AI. "2026 Microsoft Copilot Security Concerns Explained." May 6, 2026.
https://concentric.ai/too-much-access-microsoft-copilot-data-risks-explained/

[12] RansomLeak. "AI Data Leakage." April 18, 2026.
https://ransomleak.com/blog/ai-data-leakage-employees/

[13] Checkmarx. "GitHub Copilot Security: Risks, Built-In Controls, and Best Practices." May 11, 2026.
https://checkmarx.com/learn/ai-security/top-5-github-copilot-security-risks-9-ways-to-mitigate-them/

[14] Veracode. "2025 GenAI Code Security Report." 2025.
https://www.veracode.com/genai-code-security-report-2025

[15] IBM Security. "Cost of a Data Breach Report 2025."
https://www.ibm.com/reports/data-breach

[16] OpenAI. "Privacy Policy — How your data is used." 2026.
https://openai.com/policies/row-privacy-policy/

[17] OpenAI Help Center. "Manage your data in ChatGPT." 2026.
https://help.openai.com/en/articles/7730893-data-controls-faq

[18] OWASP. "LLM06:2025 Excessive Agency." OWASP LLM Top 10 2025.
https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

[19] GitHub Blog. "GitHub found 39M secret leaks in 2024." April 1, 2025.
https://github.blog/security/application-security/next-evolution-github-advanced-security/

[20] Harmonic Security. "AI Prompt Security Report 2025." 2025.
https://www.harmonic.security/research/ai-security-report-2025