MCP security checklist: як безпечно запустити server і client

Безпечний MCP rollout починається з карти довіри: хто запускає host, де живе client, хто контролює server, до яких upstream API він звертається і яка людина або workload надала повноваження. Для кожного tool зафіксуйте допустимі inputs, data scope, side effects, credential owner, approval policy та доказ виконання. Потім перевірте authorization, network egress, session integrity, недовірені tool results і recovery як окремі controls.

MCP не робить зовнішню систему безпечною автоматично. Server може мати коректний JSON-RPC контракт і водночас передавати чужий token, ходити за довільним URL або виконувати destructive tool без підтвердження. Офіційна MCP security guidance прямо виділяє confused deputy, token passthrough, SSRF, session hijacking і компрометацію local server. Checklist нижче перетворює ці класи ризику на release evidence, але не замінює threat model вашого deployment.

• Identity → чия особа або workload виконує запит.
• Authority → які resource, scope та side effect дозволені саме цьому запиту.
• Isolation → які процеси, файли, мережі й secrets недоступні server-у.
• Evidence → що дозволяє відтворити consent, policy decision і результат.
• Recovery → як відкликати token, зупинити server і компенсувати side effect.

Побудуйте data-flow diagram для host, кожного MCP client/server, authorization server, upstream resource server, browser callback, local process і audit sink. Позначте remote та local transports, tenant boundary, місце зберігання credentials і переходи, де model-generated text стає executable input. Не вважайте server довіреним лише тому, що його встановив користувач: package, update channel, transitive dependency або локальний конфіг можуть бути скомпрометовані.

Inventory має містити owner, version, transport, tools/resources/prompts, input/output schema, read/write class, data classification, upstream domains, required scopes, human approval і kill switch. Відхиляйте невідомі capabilities за замовчуванням. Capability negotiation повідомляє про підтримку функції, але не надає business authorization; дозвіл на tool call перевіряється в policy layer на кожному виклику.

Для local server використовуйте allowlisted package або pinned artifact з перевіркою походження та checksum, окремий непривілейований процес, мінімальний filesystem mount і deny-by-default egress. Перед першим підключенням покажіть користувачу точну команду, publisher, requested directories, domains і доступні tools. Оновлення version або розширення дозволів запускає повторне consent і security review.

Для protected remote server виконуйте authorization discovery, PKCE та redirect URI validation згідно з актуальним MCP authorization profile. Перевіряйте issuer, signature, expiry, audience/resource indicator і scopes на server side. Не приймайте token, виданий іншому resource, і не використовуйте один широкий credential для різних tenants або users. Scope — лише верхня межа: domain policy та object-level ACL все одно мають перевіряти конкретний invoice, repository або document.

Token passthrough — коли MCP server приймає token client-а і без належної перевірки передає його downstream API — офіційно визначений як заборонений anti-pattern. Server повинен прийняти token лише для себе, а downstream credential отримувати окремим контрольованим flow. Для OAuth proxy з одним upstream client ID зберігайте consent окремо для кожного MCP client і показуйте фактичні third-party scopes; інакше атакувальник може використати вже надану upstream згоду як confused deputy.

User-delegated Authorization Code та workload Client Credentials належать до різних authority lanes. Не підміняйте фонову service identity людським refresh token і не надавайте machine credential можливість діяти «від імені» невизначеного користувача. Secrets зберігайте у vault, видавайте короткоживуче, маскуйте в logs і перевіряйте rotation/revocation. Детальний вибір flow розглянуто у порівнянні MCP OAuth, а базову модель — у матеріалі про authorization.

Будь-який URL, endpoint або callback, який може вплинути на outbound request, розглядайте як недовірений. Використовуйте allowlist scheme/host/port, DNS та IP validation після resolution, блокування loopback, link-local, private і metadata ranges, а також контрольований egress proxy. Повторюйте перевірку після redirect і не дозволяйте tool input змінювати authorization discovery endpoint без policy. Це важливо для server-deployed clients, які мають доступ до внутрішньої мережі.

Session ID — routing handle, а не authentication. Генеруйте його криптографічно, прив’язуйте до authenticated principal і client, перевіряйте на кожному повідомленні, задавайте expiry та не приймайте session ID як доказ права. Для stateful transport тестуйте чужий ID, replay після logout, parallel reconnect, event injection і race під час rotation. Якщо core deployment stateless, усе одно захищайте transport connection, callbacks і будь-який application state над протоколом.

На stdio межі proxy не змішуйте protocol messages з shell command construction. Запускайте точний executable з аргументами як масив, очищайте environment, не передавайте довільні env names і відокремлюйте logs від protocol stdout. Remote HTTP завершуйте TLS лише у контрольованій точці, обмежуйте request/body size, concurrency та timeouts. Rate limit прив’язуйте до identity й capability, щоб один дорогий tool не виснажив спільний server.

Tool description може схилити модель до небезпечної дії, input — містити path traversal або command fragment, а result — indirect prompt injection. Валідовуйте JSON Schema, але додавайте semantic policy: allowlisted operations, canonical paths, object ownership, row limits, content types і заборонені destinations. Ніколи не вставляйте model-generated argument у shell, SQL або URL без параметризації та domain-specific validation.

Розділіть read-only, reversible write, external communication, financial/destructive і administrative tools. Для consequential action покажіть людині target, exact change, credential owner і незворотні наслідки без прихованих полів; approval прив’язуйте до payload hash і короткого expiry. Confirmation «дозволити цьому server усе» не є підтвердженням конкретного переказу, видалення або публікації.

Після tool call нормалізуйте result як untrusted data, збережіть provenance і не дозволяйте результату змінювати system policy, tool allowlist або credentials. Великі blobs обмежуйте та скануйте; resource links перевіряйте перед fetch. Для side effects використовуйте idempotency key, precondition/version і reconciliation: timeout не доводить, що дія не відбулася. Компенсація має бути спроєктована до ввімкнення write tool.

Створіть fixtures для wrong audience, expired/revoked token, overbroad scope, cross-tenant object, malicious redirect, DNS rebinding, metadata IP, stolen session ID, replay, tool-schema bypass, poisoned description/result, path traversal, duplicate side effect і crash після upstream commit. Окремо перевірте, що local server без consent не стартує, sandbox не читає сусідній secret, а deny-by-default egress справді блокує невідомий host.

Release dossier зберігає server artifact/version, capability manifest, trust diagram, policy bundle, OAuth metadata snapshot, test results, reviewer, accepted residual risks і rollback owner. Runtime signals включають authorization denials, audience/scope mismatch, new capability, egress denial, session anomaly, approval outcome, tool latency/error, duplicate suppression і compensation. Не записуйте raw tokens, confidential prompts або повні tool results лише заради observability.

Rollout починайте з read-only shadow або synthetic tenant, потім відкрийте вузьку cohort і лише після security regression — write tools. Rollback вимикає capability у registry, відкликає credentials і sessions, зупиняє local processes, блокує egress, reconcile-ить невизначені side effects і повертає попередній pinned artifact/policy. Повторюйте targeted review після зміни SDK, transport, authorization metadata, upstream API, tool schema або permission surface.

• Перед merge → threat model, pinned dependency/artifact і негативні contract tests.
• Перед pilot → synthetic credentials, sandbox/egress proof та verified kill switch.
• Перед write access → payload-bound approval, idempotency і compensation drill.
• Перед scale → cross-tenant regression, token/session revocation і audit sampling.
• Після зміни → diff capabilities та scopes, targeted tests і rollback rehearsal.