Материал

AI-generated PR attribution: кто отвечает за код, который написал Copilot, Cursor или Claude Code

Опубликовано: 14 мая 2026 Время чтения: 3 мин

Когда AI пишет код за вас — подпись под ним всё равно остаётся вашей

Введение: новая подпись в git log

Откройте git log любого активно разрабатываемого проекта 2025–2026 года — и с высокой вероятностью вы увидите строки вроде:

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Copilot <copilot@github.com>

Это не декоративный элемент. Это постоянная запись в истории репозитория, которая влечёт за собой вопросы: кто автор этого кода? Кто несёт ответственность за баг в нём? Что произойдёт, если окажется, что AI воспроизвёл лицензированный фрагмент без attribution?

AI-инструменты кодинга перешли от «умного автодополнения» к полноценным агентам, способным открывать PR, писать тесты, управлять зависимостями и деплоить изменения. Вместе с этим сдвигом возник новый класс проблем: атрибуция, ответственность и управление изменениями в эпоху агентного AI. Тема актуальна для CTO, Tech Lead и AppSec-специалистов, которые уже столкнулись с реальностью: их CI/CD принимает код, написанный не человеком.

Как работает AI-атрибуция в git: механика и инструменты

Git-трейлеры: откуда взялся Co-Authored-By

Формат Co-Authored-By — это не изобретение AI. GitHub ввёл его для pair programming: когда над коммитом работали двое, оба могли быть отражены в истории. Механика простая — git-трейлер (строка в конце commit message в формате key: value) читается GitHub и другими платформами, которые отображают соавторов коммита и учитывают их вклад в статистику.

AI-инструменты адаптировали этот механизм под свои нужды. Каждый из ведущих инструментов ведёт себя немного по-разному:

Claude Code (Anthropic) добавляет трейлер по умолчанию начиная с ранних релизов. По данным официальной документации [1], в commit message добавляются две строки:

Generated with Claude Code (https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Название модели в трейлере меняется в зависимости от того, какой именно Claude используется в сессии. PR, создаваемые через gh pr create, получают аналогичный футер в описании. Отключается через settings.json — параметр attribution [1]. Примечательно: ряд пользователей сообщал, что Claude Code добавлял трейлер через bash-инструмент даже при отключённой настройке — в таких случаях рекомендуется явная инструкция в CLAUDE.md [2].

GitHub Copilot (VS Code) получил функцию git.addAICoAuthor в версии 1.110 (март 2026). Изначально она была отключена по умолчанию. В апреле 2026 года Microsoft тихо изменила дефолт на all — и всё резко пошло не так. Подробнее об этом инциденте — в следующем разделе [3].

OpenAI Codex долгое время намеренно не добавлял никакой AI-атрибуции — коммиты через Codex были неотличимы от человеческих. В феврале 2026 года OpenAI добавил prepare-commit-msg хук, который проставляет Co-Authored-By: Codex <noreply@openai.com> по умолчанию — примерно на 10 месяцев позже Anthropic [2].

Почему Claude «везде» на GitHub

Разрыв во времени между внедрением трейлера в Claude Code и Codex породил любопытный артефакт: в 2025 году поиск по Co-Authored-By: Claude в публичных репозиториях давал значительно больше результатов, чем по Codex. Это не означало, что Claude Code использовали чаще — просто Anthropic первой начала маркировать коммиты, а OpenAI — нет [2]. Сейчас оба инструмента ведут себя одинаково.

Скандал с VS Code 1.118: когда Attribution пошла не так

Что произошло

30 апреля 2026 года Microsoft начала публичный роллаут VS Code версии 1.118. Один pull request (PR), смёрженный 16 апреля без release notes и без какого-либо уведомления пользователей, изменил одну строку конфигурации: значение параметра git.addAICoAuthor было переведено с off на all [3].

Последствия: VS Code начал добавлять Co-Authored-By: Copilot copilot@github.com ко всем коммитам, где фиксировалось хоть какое-то AI-взаимодействие — включая закрытие скобок и исправление опечаток автокомплитом. Разработчики сообщали о трейлере в коммитах, написанных вручную после того, как они лично заменили сгенерированный Copilot commit message своим собственным [4].

Реакция сообщества оказалась взрывной: обсуждение на Hacker News набрало 1 458 points и 805 комментариев. Разработчики указывали на риски для лицензионной чистоты open source, загрязнение истории репозиториев и некорректную работу инструментов, автоматически сканирующих commit metadata [4].

Член команды VS Code Дмитрий Васюра, смёрживший PR, лично вышел на Hacker News и принёс извинения: он объяснил, что намерением было поддержать клиентов, ожидающих AI-attribution в коммитах, но реализация нарушила логику отключённых AI-функций и приписывала авторство некорректно [4].

Microsoft заблокировала обсуждение PR для коллабораторов — что лишь усилило волну критики. 3 мая 2026 года вышла версия 1.119, возвращающая дефолт на off и исправляющая баг детекции [3].

Почему это важно для security-команд

Инцидент — не просто история про маркетинг или неудачный UX. Он вскрывает три системных проблемы атрибуции AI-кода в контексте безопасности [5]:

Ложные срабатывания загрязняют audit records. Если коммит помечен как AI-assisted, хотя AI не участвовал, любой последующий анализ AI-вовлечённости становится ненадёжным. Enterprise, измеряющий объём AI-assisted кода, получает завышенные показатели. Security-команда, расследующая инцидент, тратит время на ложные следы.

Ложные отрицания разрушают подотчётность. Если модель сгенерировала уязвимый участок кода, но attribution отсутствует, команда может никогда не связать дефект с AI-assisted workflow, который его произвёл. Это критически важно при incident response.

Скрытые дефолты меняют поведение пользователей. Разработчики, обнаружившие, что их инструмент изменил commit metadata без явного согласия, отключают функцию полностью — даже если более аккуратная реализация принесла бы пользу организации.

Кто юридически отвечает за AI-сгенерированный код

Базовый принцип: разработчик = ответственное лицо

Во всех ключевых юрисдикциях ответ на вопрос «кто несёт ответственность за AI-сгенерированный код» является однозначным: ответственность лежит на человеке (или организации), который этот код принял, закоммитил и ввёл в эксплуатацию.

GitHub прямо указывает в своей документации: пользователи владеют кодом, который создают с Copilot, и несут ответственность за его проверку [6]. Контрактное обязательство вендора не переопределяет нормы авторского права и не снимает с разработчика ответственности за то, что он принял в свой репозиторий.

Это означает: если AI-сгенерированный код содержит уязвимость, воспроизводит лицензированный фрагмент без attribution или нарушает условия контракта с клиентом — это проблема разработчика и его работодателя, а не Microsoft, Anthropic или OpenAI.

Авторское право: AI не является автором

В США Бюро по авторским правам последовательно придерживается позиции: авторское право защищает человеческое авторство; полностью машинно-сгенерированный материал не регистрируется [1]. Смешанные работы (AI + человек) могут быть защищены, но только в части человеческого вклада. Это означает: чем больше разработчик активно выбирает, редактирует и переосмысляет AI-вывод, тем сильнее его правовая позиция.

В ЕС действует аналогичный принцип: произведение считается охраноспособным, если оно является «собственным интеллектуальным трудом автора» (CJEU, Infopaq, 2009) [7]. Работы, полностью созданные AI без человеческого вмешательства, не подпадают под этот критерий.

На практике это создаёт инверсию: разработчик, который принял AI-код как есть, не осмыслив его, может оказаться в ситуации, где у него нет авторских прав на этот код, но есть вся ответственность за его последствия.

Doe v. GitHub: ключевой прецедент до сих пор не решён

Дело, которое определит многое — _Doe v. GitHub, Inc._ (4:22-cv-06823-JST) — продолжается. Группа анонимных разработчиков подала иск против GitHub, Microsoft и OpenAI в ноябре 2022 года, утверждая, что Copilot обучен на их лицензированном коде без Attribution и воспроизводит его без соблюдения условий открытых лицензий [8].

Районный суд в январе 2024 года отклонил большинство требований. Остался ключевой вопрос по DMCA § 1202(b): нарушает ли Copilot закон, удаляя Copyright Management Information (CMI) из обучающего кода при генерации вывода? В сентябре 2024 года суд сертифицировал интерлокуторную апелляцию, Девятый округ принял дело к рассмотрению в декабре 2024-го [8]. По состоянию на май 2026 года дело рассматривается в апелляционном суде; производство в районном суде приостановлено [9].

Значение этого дела для практиков: если Девятый округ установит, что § 1202(b) не требует «идентичности» выходного кода обучающему, это откроет путь к значительно более широкой DMCA-ответственности для AI-инструментов — и к более жёстким требованиям к атрибуции в enterprise-контрактах.

Регуляторный контекст: ЕС AI Act и GPAI-обязательства

С августа 2025 года вступили в силу положения EU AI Act, касающиеся General-Purpose AI (GPAI) моделей [10]. Провайдеры таких моделей (включая разработчиков Copilot, Claude, Codex) обязаны публиковать сводки об обучающих данных и соблюдать авторское право ЕС. В июле 2025 года Еврокомиссия опубликовала GPAI Code of Practice с главой о copyright compliance [11].

Для команд разработки это означает: следует ожидать более детальных disclosure от AI-вендоров о тренировочных данных. Это повлияет на то, как юридические отделы оценивают риски license compliance при использовании AI-сгенерированного кода в продуктах.

Параллельно Cyber Resilience Act (ЕС) требует от производителей ПО соблюдения принципов secure-by-design и проведения обязательных risk assessments [12]. Это требование применяется к ПО, выпущенному на рынок ЕС, — независимо от того, написано ли оно человеком или AI.

Attribution в PR: что реально нужно команде

Что сейчас делают инструменты

Сводка текущего поведения ведущих инструментов по состоянию на май 2026 года:

Claude Code — Co-Authored-By в коммите + attribution footer в PR по умолчанию. Настраивается через settings.json (параметр attribution), отключаемо. В названии трейлера указывается версия модели [1].

GitHub Copilot (VS Code) — git.addAICoAuthor по умолчанию off после инцидента с 1.118/1.119. Три режима: off, chatAndAgent, all [3].

OpenAI Codex — prepare-commit-msg хук с Co-Authored-By: Codex <noreply@openai.com> по умолчанию с февраля 2026. Также отключаемо [2].

Cursor — attribution на уровне коммитов не реализован нативно; часть информации об AI-вовлечённости может присутствовать в PR descriptions при использовании агентного режима.

Почему семантика Co-Authored-By неточна

Традиционный Co-Authored-By в git означает: «этот человек участвовал в создании кода — вносил намерения, дизайнерские решения, код или review». С AI ситуация принципиально другая: модель могла предложить одно выражение, сгенерировать целую функцию, рефакторить файл, написать тесты или просто ответить на вопрос до того, как разработчик написал код вручную [5]. Эти случаи не равнозначны по степени «соавторства».

Более точная модель метаданных должна разделять тип AI-вовлечённости. Пока такого стандарта нет — ни в git, ни в платформах. Инцидент с VS Code показал, насколько сложно добавить provenance к AI-инструментам, не нарушив модель доверия в dev-окружении [5].

Что реально нужно для audit trail

Для команд, которым нужен работающий audit trail AI-кода, а не просто наличие трейлера в коммите:

Возможность поиска по git log --grep="Co-Authored-By: Claude" — позволяет выделить все AI-assisted коммиты в истории репозитория [13].

PR-level маркировка — не только в коммите, но и в описании PR, чтобы reviewers сразу видели контекст.

Разграничение между частично AI-assisted (автодополнение) и полностью агентными PR — вторые требуют принципиально иного уровня review.

Сохранение attribution в истории: удалить Co-Authored-By из старых коммитов технически возможно, но это rewrite истории со всеми его последствиями для downstream.

Governance gap: только 13% репозиториев имеют AI-политику

Исследование, охватившее более 933 000 PR в популярных OSS-репозиториях (датасет AIDev), показало: только около 13% из них имели явные guidelines по использованию AI-агентов [14]. Это огромный governance gap — особенно с учётом того, что AI-инструменты уже генерируют значительную долю коммитов.

Практический вывод: attribution трейлер без политики — это запись без смысла. Команда должна определить, что она делает с этой информацией.

Безопасность AI-кода: «работает» ≠ «безопасно»

Масштаб проблемы

Исследование Clutch (июнь 2025, 800 software professionals) показало: 59% разработчиков используют AI-сгенерированный код, который они не полностью понимают [15]. Это не вопрос квалификации — это системное давление дедлайнов и скорость, с которой AI производит правдоподобно выглядящий код.

AI-инструменты демонстрируют характерные паттерны уязвимостей: SQL-инъекции, weak authentication, hardcoded secrets, неправильная настройка CORS, ошибки в session management [16]. Многие из этих проблем относятся к business logic flaws, которые плохо детектируются автоматическими сканерами, заточенными под pattern matching.

AI coding tools как вектор атаки: реальные CVE

2025–2026 годы ознаменовались документально подтверждёнными уязвимостями в самих AI-инструментах кодинга:

Cursor получил два критических CVE в 2025 году — CVE-2025-54136 (MCPoison) и CVE-2025-54135 (CurXecute). MCPoison позволял злоумышленнику внедрить persistent backdoor через модифицированные MCP-серверы, которые продолжали исполняться при каждом запуске проекта [17]. CurXecute демонстрировал, как сообщение в Slack могло инициировать remote code execution через уязвимость в обработке команд.

GitHub Copilot в начале 2026 года получил несколько CVE, связанных с VS Code-интеграцией: CVE-2026-21523 (race condition, CVSS 8.0) и CVE-2026-21518 (command injection) [5]. Это означает, что AI coding assistants перешли из категории «удобство» в категорию security boundary.

Вывод для практиков: сам инструмент, генерирующий код, может быть вектором атаки. Это дополнительный аргумент в пользу supply chain awareness — не только для зависимостей, но и для dev toolchain.

Тихие зависимости и package hallucinations

Агентные AI-инструменты, работающие автономно, могут устанавливать пакеты без явного подтверждения разработчика. Cursor, например, может автоматически инициировать установку зависимостей — что создаёт риски typosquatting и dependency confusion [16].

Package hallucinations — отдельная проблема: AI может предложить импорт несуществующего пакета, и если злоумышленник заранее зарегистрировал этот «фантомный» пакет на npm или PyPI — разработчик, не проверивший предложение, получает malicious dependency в своём lockfile.

Эти риски не всегда видны в git log, даже при наличии Co-Authored-By трейлера. Attribution фиксирует факт участия AI; она не говорит, что именно AI сделал с зависимостями, конфигурацией или инфраструктурными файлами.

Практическая часть: что проверять до merge AI-generated PR

Чеклист code reviewer при AI-assisted PR

До принятия PR, в котором есть Co-Authored-By: AI или иной маркер:

Зависимости — проверить все добавленные/обновлённые пакеты, включая транзитивные. Убедиться, что они существуют в реестре и не являются typosquat-версиями. Проверить lockfile на несоответствия.

Секреты и credentials — запустить secret scanning (pre-commit hook или CI-стадия). AI-код может содержать hardcoded API keys, fallback credentials или debug-настройки.

Конфигурация и инфраструктурные файлы — CI/CD файлы (.github/workflows, Dockerfile, .env.example) читаются хуже всего, но именно они определяют supply chain. Изменения в них требуют отдельного внимания.

Авторизация и аутентификация — AI-сгенерированные auth flows могут быть функционально корректными, но содержать business logic flaws: ошибки в session management, слишком широкий CORS, отсутствие rate limiting [15].

Лицензионная чистота — если есть подозрение на воспроизведение лицензированного кода (особенно GPL/AGPL), проверить через tools типа FOSSA или ScanCode.

Масштаб изменения — агентные PR могут затрагивать десятки файлов. Если diff слишком большой для полноценного review, разбивать на части.

Что проверять при policy-driven governance

Если в организации вводится AI coding policy (а в 2026 году это уже не опция, а необходимость), базовые элементы:

Список одобренных инструментов с разграничением: что разрешено для продуктового кода, что — только для вспомогательного, что запрещено вовсе [18].

Правило attribution: обязателен ли трейлер, в каком формате, при каком уровне AI-вовлечённости.

Golden Rule accountability: «разработчик, который коммитит код, несёт полную ответственность за его логику — независимо от того, человек или AI его написал» [18]. Это должно быть явно зафиксировано.

Автоматические gates в CI/CD: secret scanning, dependency scanning (SCA), SAST — обязательны для всех PR, не только AI-assisted.

PR template с AI-секцией: краткое описание того, что AI сделал, какие части были проверены человеком, были ли добавлены новые зависимости.

Пример PR template для AI-assisted изменений

## AI involvement
- [ ] AI tool used: (Copilot / Claude Code / Cursor / Other)
- [ ] AI-generated portions reviewed by human
- [ ] New dependencies checked (name, version, registry, license)
- [ ] Secret/credential scan run
- [ ] Infrastructure/config files reviewed separately

## Summary of changes
(краткое описание)

## Security considerations
(что проверено, что требует дополнительного внимания)

Ошибки и антипаттерны

"У коммита есть Co-Authored-By — значит, мы задокументировали AI"

Attribution — это артефакт процесса, а не результат security review. Трейлер фиксирует участие AI в написании кода, но ничего не говорит о том:

Были ли зависимости проверены.
Содержит ли код уязвимости.
Соответствует ли он лицензионным требованиям.
Корректно ли он обрабатывает edge cases.

"Мы видим Co-Authored-By в PR" ≠ "мы контролируем AI-assisted изменение".

"AI написал код — значит, он не наш"

Юридически это неверно. Ни в США, ни в ЕС AI не является правовым субъектом, которому можно делегировать ответственность. Разработчик, принявший код, — его правовой владелец (в части, где есть человеческий вклад) и лицо, несущее ответственность за последствия [1].

"Мы запретили AI — значит, его у нас нет"

По данным исследования на базе 85% разработчиков, использующих AI-инструменты к 2025 году [18], shadow AI — реальность. Запрет без технических controls и без культуры открытости создаёт ситуацию, когда AI-код всё равно попадает в репозиторий, но без attribution и без visibility для команды безопасности.

"PR большой, но CI прошёл — значит, всё в порядке"

Агентные AI могут создавать PR, затрагивающие десятки файлов. CI/CD с базовыми тестами и линтерами проверяет функциональность и синтаксис, но не security logic, не правильность конфигурации и не лицензионную чистоту зависимостей.

Кейсы и сценарии

Сценарий 1: Тихая зависимость

Разработчик просит Claude Code реализовать интеграцию с платёжным провайдером. AI добавляет в package.json пакет с названием, близким к популярной библиотеке (одна буква отличается). Коммит идёт с Co-Authored-By: Claude. CI проходит — пакет устанавливается. Через неделю security-команда обнаруживает, что пакет является malicious typosquat.

Что должно было сработать: dependency scanning в CI/CD (SCA-инструмент, проверяющий новые пакеты в lockfile), review rule для любых изменений в package.json/requirements.txt.

Сценарий 2: Attribution загрязняет историю

Enterprise использует VS Code 1.118 в период до обновления. Тысячи коммитов получают Co-Authored-By: Copilot — включая те, где Copilot не использовался. Юридический отдел начинает аудит AI-вовлечённости перед сделкой M&A. Данные из git log оказываются ненадёжными: нельзя отличить реальные AI-assisted коммиты от артефактов бага.

Что должно было сработать: явная политика attribution, мониторинг изменений в tool defaults при обновлениях, регулярная проверка commit trailers на соответствие ожиданиям.

Сценарий 3: Аgentic PR без review gate

Команда настраивает Claude Code в агентном режиме: он самостоятельно создаёт PR с решением issue. PR создаётся ночью; утром дежурный разработчик мёржит его, бегло просмотрев diff. В PR — новый environment variable с debug-флагом (DEBUG=true), который случайно попадает в production через конфигурацию. Включает детальное логирование с PII пользователей.

Что должно было сработать: обязательный human review для всех агентных PR (не только просмотр, но и явный approve), проверка конфиг-файлов и env-переменных как отдельный gate.

Будущее: стандарты и регуляторика

Ожидаемое развитие норм атрибуции

Инцидент с VS Code 1.118 стал индикатором: opt-out дефолты для AI-attribution вызывают резкий отпор. Реалистичный прогноз — переход к явным opt-in стандартам с разными уровнями детализации [4].

Вероятные направления:

Стандартизация семантики AI-трейлеров (тип вовлечённости: suggestion vs agent vs full generation).
Repository scanning tools, проверяющие корректность attribution.
Enterprise-требования к явной атрибуции AI-кода в government и regulated contracts.
Более чёткие DMCA-прецеденты из Девятого округа, которые определят, что именно требует attribution при обучении и генерации.

EU AI Act: что ждать командам к 2026–2028

Полная применимость AI Act — 2 августа 2026 года для большинства положений [10]. Для enterprise-команд, работающих с EU-клиентами:

Провайдеры GPAI-моделей будут публиковать более детальные данные об обучающих корпусах — это улучшит возможности compliance due diligence.
Требования Cyber Resilience Act к software security будут применяться к ПО на EU-рынке, написанному с AI-помощью не иначе, чем к написанному вручную [12].
В 2025 году Еврокомиссия уточнила, что GPAI Code of Practice охватывает все стадии тренировки, включая fine-tuning и RLHF, но не inference-данные [11].

Слой контроля до merge: где HighVibe вписывается в этот контекст

Проблема, которую вскрывает вся история с AI-attribution, не в том, что у коммита нет подписи. Проблема в том, что между скоростью, с которой AI генерирует изменения, и скоростью, с которой команда их контролирует, образовался разрыв.

Co-Authored-By решает задачу видимости: кто (что) участвовал в написании кода. Но он не отвечает на вопрос, который реально важен перед merge: безопасно ли принимать это изменение прямо сейчас?

Именно в этот разрыв входит HighVibe — слой контроля, который анализирует конкретное изменение: что именно поменялось в коде, конфигурации и зависимостях, есть ли новые или обновлённые пакеты с проблемами, что несёт релизный контекст. Инструмент не замещает SAST/SCA/SBOM — он добавляет слой поверх них, фокусируясь на конкретном PR и давая короткий ответ: можно ли безопасно принять это изменение, или есть что-то, что действительно блокирует merge.

Для команд, активно использующих AI-кодинг, это особенно актуально: агентные PR создаются быстро, дифы дочитывают не всегда до конца, а новые зависимости приезжают незаметно.

Заключение: ответственность не делегируется

AI-инструменты кодинга изменили то, как пишется код. Они не изменили то, кто за него отвечает.

Co-Authored-By трейлер — полезный инструмент прозрачности, но не механизм контроля. Юридически, контрактно и операционно ответственность за принятый AI-код остаётся на разработчике и организации.

Что из этого следует на практике:

Атрибуция без политики бессмысленна — определите, что ваша команда делает с информацией о AI-вовлечённости в коммитах.

Включите AI-generated PR в обычный security lifecycle: те же ветки с защитой, тот же peer review, те же автоматические проверки.

Отдельное внимание — зависимостям, конфигурации и CI/CD файлам: именно здесь AI чаще всего вносит незаметный риск.

Следите за правовой динамикой: решение Девятого округа по Doe v. GitHub может изменить требования к attribution в enterprise-контрактах.

Attribution в git — это начало аудита, а не его конец.

Источники

[1] Claude Code Docs — "Claude Code settings" — https://code.claude.com/docs/en/settings

[2] Medium / codeai — "Why Claude is Everywhere on GitHub and Codex Just Caught Up" — https://medium.com/@codeai/why-claude-is-everywhere-on-github-and-codex-just-caught-up-9dd4fabf82aa

[3] Microsoft / vscode GitHub — "Update on Co-authored-by: Copilot in commit messages · Issue #314311" — https://github.com/microsoft/vscode/issues/314311

[4] Startup Fortune — "Microsoft's VS Code Copilot co-author blunder reveals the governance tension in AI developer tools" — https://startupfortune.com/microsofts-vs-code-copilot-co-author-blunder-reveals-the-governance-tension-in-ai-developer-tools/

[5] Penligent — "VS Code Copilot Co-Author, When AI Attribution Becomes a Supply Chain Trust Problem" — https://www.penligent.ai/hackinglabs/vs-code-copilot-co-author-when-ai-attribution-becomes-a-supply-chain-trust-problem/

[6] GitHub — "GitHub Copilot · Your AI pair programmer" — https://github.com/features/copilot

[7] AIPPI — "Approaches to IP protection for works generated by artificial intelligence: European standards" — https://www.aippi.org/news/approaches-to-ip-protection-for-works-generated-by-artificial-intelligence-european-standards/

[8] Joseph Saveri Law Firm — "GitHub Copilot Intellectual Property Litigation" — https://www.saverilawfirm.com/our-cases/github-copilot-intellectual-property-litigation

[9] Courthouse News Service — "AI companies urge Ninth Circuit to make copyright decisions clear" — https://courthousenews.com/ai-companies-urge-ninth-circuit-to-make-copyright-decisions-clear/

[10] European Union — "AI Act | Shaping Europe's digital future" — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

[11] Clifford Chance — "Copyright compliance under the EU AI Act for GPAI model providers" — https://www.cliffordchance.com/insights/resources/blogs/ip-insights/2025/10/copyright-compliance-under-the-eu-ai-act-for-gpai-model-providers.html

[12] Lawfare Media — "When the Vibes Are Off: The Security Risks of AI-Generated Code" — https://www.lawfaremedia.org/article/when-the-vibe-are-off--the-security-risks-of-ai-generated-code

[13] Coding Cocoon — "Removing Claude Code Attribution from Git Commits and PRs" — https://codingcocoon.com/posts/removing-claude-code-attribution-from-commits-and-prs/

[14] Emergent Mind — "AI-Assisted Pull Requests" — https://www.emergentmind.com/topics/ai-assisted-pull-requests-prs

[15] Clutch.co — "Blind Trust in AI: Most Devs Use AI-Generated Code They Don't Understand" — https://clutch.co/resources/devs-use-ai-generated-code-they-dont-understand

[16] Endor Labs — "Cursor Security: How to Secure AI-Generated Code in 2026" — https://www.endorlabs.com/learn/cursor-security

[17] Trax Tech — "AI Coding Tools Face Major Security Crisis" — https://www.traxtech.com/ai-in-supply-chain/ai-coding-tools-face-major-security-crisis

[18] AI Dev Day India — "Enterprise AI Coding Policy Template 2026" — https://aidevdayindia.org/blogs/best-ai-mode-checker/enterprise-ai-coding-policy-template-2026.html