AgentBaiting: як перевіряти AI Skills, MCP-сервери й агентські плагіни до встановлення

Ваш AI-агент може не просто знайти корисний MCP-сервер. Він може знайти malware і чемно принести вам інструкцію з README. Island Security Research описали AgentBaiting у кампанії FakeGit: близько 7 600 шкідливих GitHub-репозиторіїв, понад 800 з них маскувалися під AI Skills або MCP-сервери. Частина таких проектів потрапляла в публічні AI/MCP-каталоги. Payload: SmartLoader, далі StealC для крадіжки credentials, browser sessions, cookies і токенів.

AI

Логин Свят

8/18/20263 min read

AgentBaiting: як перевіряти AI Skills, MCP-сервери й агентські плагіни до встановлення

AI-агенти поступово стають не тільки помічниками для написання коду, а й посередниками в software discovery. Розробник просить: “знайди MCP для Jenkins”, “дай skill для Google Workspace”, “підключи Databricks до агента”. Агент шукає, читає README, порівнює варіанти й часто повертає інструкцію встановлення.

Саме тут з’являється новий supply chain-ризик. У класичному сценарії атакувальник переконував людину натиснути посилання. У AgentBaiting людина може взагалі не бачити первинну приманку: її знаходить агент.

Що змінилося

Island Security Research 20 липня 2026 описали FakeGit-операцію: приблизно 7 600 шкідливих репозиторіїв, близько 6 600 профілів, понад 800 репозиторіїв під виглядом AI Skills або MCP-серверів. Кампанія використовувала copied projects, lookalike developer profiles, переконливі README і ZIP-файли з Windows payload. За даними Island, частина репозиторіїв була присутня в публічних AI/MCP-каталогах, а в тестах Claude Code, Gemini і ChatGPT могли самостійно surfaced malicious campaign repositories без переданого користувачем лінка.

Технічний ланцюг типовий для supply chain malware: репозиторій виглядає як корисний integration package, README веде до ZIP, всередині .cmd/.bat, runtime на кшталт LuaJIT і обфускований payload. Далі SmartLoader встановлює persistence і доставляє StealC, який націлений на browser passwords, cookies, active sessions, tokens та інші дані endpoint.

Важлива межа: це не означає, що кожен AI-асистент завжди встановить malware сам. У частині тестів агент міг помітити підозрілий вміст. Але для enterprise достатньо самої можливості: агентська рекомендація стала discovery channel для malware.

Кому це корисно

CTO і tech leads: потрібен процес закупівлі й дозволу агентських capability, як для SaaS або dependency.

Developers: не можна ставити MCP/skill/plugin тільки тому, що агент знайшов “найкращий варіант”.

QA / test automation: тестові агенти часто просять доступ до браузера, Playwright, Jira, GitLab, test data. Це приваблива зона для викрадення токенів.

SOC / security engineers: треба моніторити не лише browser downloads, а й agent-initiated clone/download/install paths.

Практичні кейси

  1. Intake для нового MCP-сервера
    Команда хоче MCP для Jira або Jenkins. Замість “знайшли на GitHub і встановили” створюється Jira issue з repo URL, publisher, requested scopes, install method, hash, sandbox result і owner approval.

  2. Захист GitLab MR
    Будь-яка зміна .mcp.json, .claude/settings*, .cursor/*, agents/*, install scripts, ZIP/EXE/BAT/CMD файлів запускає CI job. Якщо немає security approval label, pipeline падає.

  3. Sandbox для agent capability
    Новий skill тестується в disposable VM/container без browser sessions, SSH keys, cloud credentials, production env vars і real customer data. Якщо install path вимагає Windows ZIP/EXE для “MCP server”, це red flag.

  4. SOC hunting
    SOC отримує список відомих IOC/hash з research artifacts, шукає downloads, process execution, scheduled tasks, підозрілі GitHub release assets і agent config changes.

Playbook впровадження

  1. Зробіть allowlist
    Створіть security/ai-capabilities.yml:

approved:
- name: jira-readonly-mcp
repo: https://github.com/company/jira-readonly-mcp
version: v1.2.0
sha256: "EXPECTED_HASH"
scopes: ["jira:read"]
owner: "platform-security"

  1. Додайте Jira workflow
    Issue type: AI Capability Intake.


Поля:

  • capability name;

  • repo/package URL;

  • publisher/maintainer;

  • install command;

  • requested permissions;

  • data touched;

  • sandbox result;

  • rollback plan;

  • approver.

  1. Додайте GitLab CI gate

ai_capability_guard:
image: python:3.12-slim
stage: test
rules:
- changes:
- ".mcp.json"
- ".claude/**/*"
- ".cursor/**/*"
- "agents/**/*"
- "skills/**/*"
- "**/*.zip"
- "**/*.exe"
- "**/*.bat"
- "**/*.cmd"
script:
- python scripts/check_ai_capabilities.py
artifacts:
when: always
paths:
- ai-capability-review.json

  1. Мінімальний Python checker


import json, pathlib, sys, yaml

approved = yaml.safe_load(open("security/ai-capabilities.yml"))["approved"]
approved_repos = {item["repo"] for item in approved}

changed = [p.strip() for p in open("changed_files.txt")]
risky_ext = (".zip", ".exe", ".bat", ".cmd", ".ps1")

findings = []
for file in changed:
if file.endswith(risky_ext):
findings.append({"file": file, "reason": "binary/script install artifact needs security review"})

if file.endswith(".mcp.json"):
data = json.load(open(file))
for server in data.get("mcpServers", {}).values():
repo = server.get("repo") or server.get("url")
if repo and repo not in approved_repos:
findings.append({"file": file, "reason": f"unapproved MCP source: {repo}"})

open("ai-capability-review.json", "w").write(json.dumps(findings, indent=2))
if findings:
print(json.dumps(findings, indent=2))
sys.exit(1)

  1. Slack alert
    У GitLab failure hook або scheduled job відправляйте в Slack:

curl -X POST "$SLACK_WEBHOOK_URL" \ -H 'Content-type: application/json' \ --data "{\"text\":\"AI capability review failed in $CI_PROJECT_PATH: $CI_PIPELINE_URL\"}"

Приклади промптів

Промпт для агента перед recommendation:

Перевір цей MCP/Skill як supply-chain dependency.
Не давай install instructions, доки не перевіриш:
1. хто maintainer;
2. чи repo лінкується з офіційного сайту;
3. чи є releases з binary ZIP/EXE;
4. які permissions потрібні;
5. чи є підозрілі scripts, obfuscation, one-character lookalike author;
6. чи можна запустити в sandbox без real secrets.
Поверни verdict: approve / reject / needs manual review.

Jira JQL для черги review:

project = SEC AND issuetype = "AI Capability Intake" AND status in ("Open", "In Review") ORDER BY created DESC

Security policy:

AI agents may recommend tools, but may not install, execute, or configure new MCP servers, Skills, browser extensions, CLIs, or plugins unless the capability exists in the approved catalog and runs with scoped test credentials first.

Чекліст впровадження

  • Є owner для кожного MCP/Skill/plugin.

  • Є allowlist з repo, version, hash, scopes.

  • Agent не має production secrets під час discovery.

  • ZIP/EXE/BAT/CMD install paths блокуються без approval.

  • Tool descriptions і schema проходять review як prompt surface.

  • OAuth scopes мінімальні й per-server.

  • Є журнал agent-initiated clone/download/execute actions.

  • Є IR-процедура: isolate endpoint, revoke sessions, rotate tokens.

Ризики й обмеження

Не можна покладатися тільки на LLM-verdict: Microsoft прямо показує, що prompt-only policy не є security boundary. Registry listing теж не доводить легітимність: Island описує випадки, де публічні каталоги відтворювали attacker README. Hash pinning допомагає тільки після review; він не робить malware безпечним. Для production потрібні EDR, egress control, секрети короткого життя, scoped OAuth і human approval для capability changes.

Як виміряти користь

Before/after signals:

  • скільки MCP/skills встановлено без owner;

  • скільки agent config changes проходять review;

  • mean time to approve safe capability;

  • кількість blocked risky install artifacts;

  • кількість токенів/секретів, доступних agent sandbox;

  • час пошуку IOC після advisory.

Ідеї для агентів

  • Capability Intake Agent: читає Jira request, repo, README, permissions; повертає risk summary.

  • MCP Diff Agent: порівнює tool schema між версіями й ловить rug-pull зміни.

  • Sandbox Runner Agent: запускає новий skill у disposable env без secrets і збирає поведінку.

  • GitLab Guard Agent: коментує MR, якщо змінили agent config або додали binary install path.

  • IOC Hunt Agent: бере CSV/hash з vendor artifacts і шукає збіги в EDR/SIEM.

  • Slack Approval Agent: збирає approval від owner/security для low-risk capability.

  • Token Scope Auditor: перевіряє OAuth scopes MCP-серверів проти policy.

  • Registry Monitor: стежить за MCP/Skill каталогами для lookalike names вашої компанії.

Практичний playbook: як застосувати за 1-2 години

  1. Prerequisites: GitLab project, Jira project для security review, Slack webhook, список поточних MCP/skills/plugins.

  2. Мінімальний приклад: створіть security/ai-capabilities.yml, додайте CI job, який блокує unapproved .mcp.json і binary install artifacts.

  3. Інтеграція: GitLab CI блокує MR; Jira issue зберігає approval; Slack отримує alert; Python checker генерує JSON-звіт.

  4. Перевірка: зробіть тестовий MR з новим .mcp.json і .zip; pipeline має впасти без approval.

  5. Не робити в production: не давати агенту встановлювати знайдений MCP/Skill з реальними токенами, не запускати downloaded executable, не довіряти registry listing як доказу легітимності.


Джерела