Agentic SAMM / ASAMM: зрелость защиты AI-агентов

Agentic SAMM (ASAMM) - прикладная модель зрелости для систем, где LLM не просто отвечает в чате, а действует: вызывает инструменты, пишет код, ходит в MCP-серверы, читает RAG, использует память, маршрутизируется между провайдерами и может тратить деньги клиента.

Для Spectorn это не отдельная "бумажная" методика, а карта продукта:

API-шлюз: клиент получает OpenAI-compatible API, доступные ему модели, BYOK или hosted-provider routing, политики, лимиты, аудит и защиту на входе/выходе.
Защитный контур: клиент может купить не весь шлюз, а слой проверки промптов, ответов, RAG, инструментов, агентов и webhooks.
Память: отдельный слой для provenance, TTL, изоляции tenant, удаления, сканирования poisoning и контроля долгоживущего контекста.
Кабинет и админка: владелец видит ключи, провайдеров, политики, логи, evidence, статус и зрелость agentic security.

ASAMM полезен потому, что у агентных систем поверхность атаки шире, чем у классического API: уязвимость может жить в tool schema, системном промпте, памяти, MCP-транспорте, fallback-маршруте модели, billing-логике, webhook или старом JWT.

Источники и статус

ASAMM - развивающаяся практика, а не завершенный ISO-стандарт. В этом материале мы используем ее как инженерный чеклист, совмещая идеи из обзора Agentic SAMM на Habr, открытого репозитория scadastrangelove/asamm и практики defensive security assessment Spectorn.

Пять доменов ASAMM

Домен	Что защищает	Что дает в Spectorn
AG - Agentic Governance	Инвентарь, риск, автономность, комплаенс, человеческая ответственность	Tenant policy, API keys, provider policy, ASAMM posture, audit
AD - Agentic Design	Архитектура агентов, MCP, инструментов, памяти и trust boundaries	Референсные схемы API gateway, protection-only и gateway+memory
AI - Agentic Implementation	Промпты, контекст, tool calls, память, coding agents, identity	Gateway enforcement, BYOK, prompt/context checks, memory controls
AV - Agentic Verification	Threat model, red-team, regression, jailbreak/prompt injection tests	Black-box checks, vitest/cargo gates, release-evidence
AO - Agentic Operations	Monitoring, incident response, drift, vulnerability management, deploy	Status, logs, self-defense, nginx/Docker hardening, smoke tests

21 контролей

ID	Контроль	Spectorn baseline	Следующее усиление
AG-1	Automated Discovery, Inventory and Risk Profiling	Провайдеры, модели, ключи, tenant metadata	Реестр агентов/MCP с владельцем, data class и autonomy budget
AG-2	Autonomy Policy Management	Политики, allow/deny моделей, API-key scope	Бюджеты автономности на ключ/агента/tool-chain
AG-3	Adaptive Risk Management	Self-defense, scan history, rate limits	Автоужесточение политик при росте риска
AG-4	Dynamic Compliance Management	NIST AI RMF, EU AI Act, MITRE ATLAS, OWASP LLM Top 10 в библиотеке	Экспорт ASAMM evidence pack для аудита
AG-5	Human Oversight and Accountability	Admin audit, роли, protected admin shell	Approval gates для hosted-provider, destructive tools и memory writes
AD-1	Secure Agentic Architecture	Nginx split, Docker compose, dashboard middleware, gateway policy	Референсные схемы под разные режимы покупки
AD-2	MCP Security and Toolchain Governance	MCP docs, tool injection playbooks	MCP registry, signed metadata, tool allowlists, private egress policy
AD-3	Agentic Data Flow and Trust Boundary Mapping	Webhook tests, OpenAPI route, log redaction, dashboard API auth	Data-flow diagram по включенным провайдерам, webhooks, memory и policies
AI-1	Prompt and Context Engineering	Scan endpoint, playground, prompt-injection detection	Context provenance labels в логах и кабинете
AI-2	Autonomous Tool Invocation Security	Excessive agency playbook, policy hooks	Tool-call firewall events: tool, schema hash, input/output risk
AI-3	Memory Systems Security	RAG poisoning, data exfiltration, retention guidance	Memory gateway: provenance, TTL, redaction, tenant isolation, erase evidence
AI-4	Agentic Coding Security	Regression gates, dependency overrides, release evidence	Фирменный CLI evidence для diff/dependency/code-agent checks
AI-5	Identity and Access Control for Agents	API-key lifecycle, BYOK, stale-token handling, tenant policy snapshot	Agent identity claims и per-agent revocation
AV-1	Agentic Threat Modeling and Risk Assessments	Auth, API keys, routing, SSRF, admin, nginx, Docker audit map	Tenant wizard и downloadable ASAMM risk register
AV-2	Security Testing of Agentic Behavior	Black-box checks, API-key tests, webhook tests, middleware tests	Safe simulated tool-use probes без атаки сторонних провайдеров
AV-3	Agentic Security Regression Testing	Vitest, cargo, smoke, release-evidence	Ежедневный production-safe synthetic security suite
AV-4	Robustness Testing against Jailbreak and Prompt Injection	Threat library, scan endpoint, playground, policies	Отраслевые red-team packs с before/after evidence
AO-1	Autonomous Monitoring and Incident Response	Status, logs, engine health, self-defense	Incident timeline export и tenant-facing recovery actions
AO-2	Agentic Drift and Anomaly Detection	Logs, billing, provider health, scan history	Baselines по tool chains, memory access, spend spikes, fallback
AO-3	Agentic Vulnerability Management	Dependency overrides, launch preflight, academy	Vulnerability inventory для MCP, prompt templates, SDK, integrations
AO-4	Secure Deployment and Configuration Management	TLS, CORS, metrics token, registration gate, direct-origin nginx	Signed deployment evidence manifest

Режимы клиента Spectorn

1. Клиент покупает API-шлюз

Клиенту не нужен новый SDK и не нужно перестраивать приложение. Базовый путь:

Заменить base_url на https://spectorn.xyz/v1.
Использовать Spectorn API key.
Выбрать доступную модель или alias.
При BYOK передавать ключ провайдера в согласованном заголовке.
Получать защиту, маршрутизацию, лимиты, логи и evidence через Spectorn.

Главная ценность: клиент не строит собственный multi-provider gateway, не решает вопрос OpenRouter-like доступности, не хранит все guardrails в приложении и получает единый слой контроля.

2. Клиент покупает только защиту

Если клиент не хочет менять модельный шлюз, Spectorn работает как защитный контур:

pre-flight scan для входящих промптов;
post-flight scan для ответов;
RAG и memory scan;
webhook/event intake;
policy decision API;
evidence для SOC, compliance и разборов инцидентов.

В этом режиме важно не требовать от клиента переноса трафика моделей. Spectorn должен быть легко добавляемым guardrail рядом с существующим стеком.

3. Клиент покупает gateway + protection + memory

Это максимальный режим: Spectorn контролирует provider routing, политики, ключи, защиту, память и evidence. Здесь ASAMM раскрывается полностью: агент получает управляемую идентичность, memory provenance, tool-call контроль, drift/anomaly detection и audit trail.

Отраслевые сценарии

Банки, финансы, HFT

Риски: prompt injection в аналитике, утечка PII/PCI, tool-call к платежам, злоупотребление провайдерским fallback, дорогое потребление токенов.

Контроли: AG-2, AI-5, AI-3, AV-2, AO-2.

Что делать:

разделять ключи по продуктам и агентам;
запрещать высокорисковые модели для regulated workflows;
включать spend limits и anomaly alerts;
хранить evidence по каждому blocked или downgraded запросу;
проверять RAG и память на poisoning.

Телеком и NOC-агенты

Риски: агент получает доступ к NOC-инструментам, меняет конфигурацию, раскрывает данные абонентов, вызывает tools слишком часто.

Контроли: AD-2, AI-2, AO-1, AO-2, AV-3.

Что делать:

строить MCP/tool allowlist;
требовать approval для destructive network actions;
отделять наблюдение от изменения конфигураций;
вести tool-call evidence;
отслеживать drift по частоте команд и шаблонам запросов.

Госсектор и КИИ

Риски: data residency, суверенные модели, air-gapped deployment, supply chain, insider misuse, компрометация памяти.

Контроли: AG-4, AD-1, AI-3, AI-5, AO-4.

Что делать:

использовать self-hosted deployment;
отключать внешние provider fallback;
закреплять разрешенные модели и провайдеры на уровне tenant policy;
хранить evidence локально;
строить отдельный контур для памяти и удаления данных.

Healthcare и PII/PHI

Риски: PHI в промптах, hallucination в рекомендациях, долгоживущая память пациента, RAG poisoning в базе знаний.

Контроли: AI-1, AI-3, AV-4, AG-5, AD-3.

Что делать:

маркировать контекст по источнику и классу данных;
маскировать PII/PHI до провайдера;
хранить TTL и erase evidence для памяти;
разделять clinical support и administrative assistants;
не давать агенту автономно принимать медицинские решения.

SaaS, support, chatbots

Риски: prompt injection от пользователя, раскрытие system prompt, утечка CRM, tool-call к billing/support actions, публичная регистрация abuse.

Контроли: AI-1, AI-2, AV-4, AO-1, AG-2.

Что делать:

включать prompt injection и data exfiltration checks;
ограничивать инструменты support-агента;
делать per-tenant API keys;
логировать blocked actions без секретов;
использовать safe fallback вместо прямой передачи ошибки модели пользователю.

DevSecOps и coding agents

Риски: агент пишет небезопасный diff, добавляет зависимость, раскрывает секреты в логах, меняет deploy config, игнорирует тесты.

Контроли: AI-4, AV-3, AO-3, AO-4, AG-5.

Что делать:

требовать evidence по diff и dependency changes;
гонять security regression tests до deploy;
блокировать секреты в prompt/log/output;
проверять Docker/nginx/env изменения отдельными тестами;
отправлять high-risk изменения на human approval.

MCP и инструменты

MCP делает агента полезным, но резко увеличивает blast radius. Минимальный baseline:

реестр MCP-серверов: владелец, версия, transport, auth, data classes;
signed metadata или хотя бы pinned config;
tool allowlist на tenant/key/agent;
запрет private IP egress, если tool ходит наружу;
schema hash и evidence для каждого tool call;
разделение read-only и write/destructive tools;
approval для действий, которые меняют деньги, доступы, данные или инфраструктуру.

Память

Память нельзя считать просто "длинным контекстом". Это persistent attack surface.

Минимальный baseline:

provenance: кто записал, из какого запроса, каким policy decision;
TTL и expiration;
tenant isolation;
redaction до записи;
poisoning scan;
erase evidence;
запрет автоматического повышения trust уровня старой памяти;
отдельные правила для user memory, org memory, vector memory и tool-derived memory.

Что должно быть в evidence pack

Для промышленного клиента полезен не красивый отчет, а набор проверяемых артефактов:

список моделей, провайдеров и aliases;
ключи и их tenant-scoped policy snapshot без секретов;
включенные policies и guardrails;
blocked/allowed decisions по тестовым сценариям;
webhook secret handling;
CORS/origin/TLS/nginx posture;
Docker ports, networks, volumes, healthchecks;
результаты security regression tests;
ASAMM maturity score;
список открытых high-risk gaps.

Минимальный launch checklist

API gateway отвечает на health и OpenAI-compatible endpoints.
Регистрация либо закрыта, либо защищена от abuse.
API-key lifecycle работает: issuance, revoke, rotation, tenant scope.
Hosted-provider fallback не включается без политики tenant.
BYOK не логируется и не попадает в evidence.
SSRF/private IP egress закрыт для provider base_url и tool URLs.
Dashboard/admin требуют auth и role checks.
Public metadata не раскрывает секреты, internal ports, metrics token.
Nginx/TLS/CORS/Host header проверены black-box.
Docker не публикует Postgres/Redis наружу.
Память имеет хотя бы минимальный режим: provenance, TTL, erase.
Release-evidence хранится рядом с деплоем.

FAQ

ASAMM заменяет OWASP LLM Top 10?

Нет. OWASP LLM Top 10 хорошо описывает классы угроз, а ASAMM помогает организовать зрелость: кто владеет контролем, где evidence, как проверить, что защита работает постоянно.

Клиенту API-шлюза нужно менять весь код?

Нет. Базово меняется base_url, ключ и выбранная модель/alias. Это и есть ценность шлюза: сложность multi-provider routing, политики и защита уезжают в Spectorn.

Почему память вынесена отдельно?

Потому что память переживает один запрос. Если ее отравили, украли или неправильно переиспользовали, атака становится долгоживущей.

Можно ли использовать ASAMM для protection-only клиента?

Да. Тогда основные домены - AI, AV и AO: scan, policy decision, evidence, regression, incident response. Governance и Design остаются как рекомендации для зрелости.