Agentic SAMM / ASAMM: maturity for AI agent security

Agentic SAMM (ASAMM) is an applied maturity model for systems where an LLM does more than answer in a chat. The agent can call tools, write code, reach MCP servers, read RAG, use memory, route between providers, and spend customer budget.

For Spectorn this is not a paper-only framework. It is a product map:

API gateway: the customer receives an OpenAI-compatible API, available models, BYOK or hosted-provider routing, policies, limits, audit, and protection at the gateway boundary.
Protection layer: the customer can buy a protective scan and policy layer without moving all model traffic into the gateway.
Memory layer: provenance, TTL, tenant isolation, erase evidence, poisoning checks, and long-lived context control.
Cabinet and admin panel: owners see keys, providers, policies, logs, evidence, status, and agentic security maturity.

ASAMM is useful because agentic systems have a wider attack surface than a classic API: a weakness may live in a tool schema, system prompt, memory record, MCP transport, model fallback route, billing rule, webhook, or stale JWT.

Sources and status

ASAMM is an emerging practice, not a completed ISO standard. This guide uses it as an engineering checklist, combining ideas from the Agentic SAMM article on Habr, the open scadastrangelove/asamm repository, and Spectorn defensive security assessment work.

Five ASAMM domains

Domain	What it protects	What it gives in Spectorn
AG - Agentic Governance	Inventory, risk, autonomy, compliance, human accountability	Tenant policy, API keys, provider policy, ASAMM posture, audit
AD - Agentic Design	Agent, MCP, tool, memory, and trust-boundary architecture	Reference designs for API gateway, protection-only, and gateway+memory
AI - Agentic Implementation	Prompts, context, tool calls, memory, coding agents, identity	Gateway enforcement, BYOK, prompt/context checks, memory controls
AV - Agentic Verification	Threat model, red-team, regression, jailbreak and prompt-injection testing	Black-box checks, vitest/cargo gates, release-evidence
AO - Agentic Operations	Monitoring, incident response, drift, vulnerability management, deployment	Status, logs, self-defense, nginx/Docker hardening, smoke tests

21 controls

ID	Control	Spectorn baseline	Next hardening step
AG-1	Automated Discovery, Inventory and Risk Profiling	Providers, models, keys, tenant metadata	Agent/MCP registry with owner, data class, and autonomy budget
AG-2	Autonomy Policy Management	Policies, model allow/deny, API-key scope	Autonomy budgets per key, agent, and tool-chain
AG-3	Adaptive Risk Management	Self-defense, scan history, rate limits	Automatic policy tightening when risk increases
AG-4	Dynamic Compliance Management	NIST AI RMF, EU AI Act, MITRE ATLAS, OWASP LLM Top 10 in the library	Exportable ASAMM evidence pack
AG-5	Human Oversight and Accountability	Admin audit, roles, protected admin shell	Approval gates for hosted-provider enablement, destructive tools, and memory writes
AD-1	Secure Agentic Architecture	Nginx split, Docker compose, dashboard middleware, gateway policy	Reference architectures for each customer purchase mode
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 from enabled providers, webhooks, memory, and policies
AI-1	Prompt and Context Engineering	Scan endpoint, playground, prompt-injection detection	Context provenance labels in logs and cabinet
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	Branded CLI evidence for 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 and per-agent revocation
AV-1	Agentic Threat Modeling and Risk Assessments	Auth, API keys, routing, SSRF, admin, nginx, Docker audit map	Tenant wizard and 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 without attacking third-party providers
AV-3	Agentic Security Regression Testing	Vitest, cargo, smoke, release-evidence	Daily production-safe synthetic security suite
AV-4	Robustness Testing against Jailbreak and Prompt Injection	Threat library, scan endpoint, playground, policies	Industry red-team packs with before/after evidence
AO-1	Autonomous Monitoring and Incident Response	Status, logs, engine health, self-defense	Incident timeline export and tenant-facing recovery actions
AO-2	Agentic Drift and Anomaly Detection	Logs, billing, provider health, scan history	Baselines for tool chains, memory access, spend spikes, fallback
AO-3	Agentic Vulnerability Management	Dependency overrides, launch preflight, academy	Vulnerability inventory for MCP, prompt templates, SDKs, integrations
AO-4	Secure Deployment and Configuration Management	TLS, CORS, metrics token, registration gate, direct-origin nginx	Signed deployment evidence manifest

Spectorn customer modes

1. Customer buys the API gateway

The customer does not need a new SDK or a full application rewrite. The baseline path is:

Set base_url to https://spectorn.xyz/v1.
Use a Spectorn API key.
Pick an available model or alias.
For BYOK, pass the provider key in the agreed header.
Receive protection, routing, limits, logs, and evidence through Spectorn.

The value is simple: the customer does not build a multi-provider gateway, does not depend on a single OpenRouter-like path, does not keep all guardrails inside app code, and gets one control plane.

2. Customer buys protection only

If the customer does not want to move model traffic, Spectorn acts as a protection layer:

pre-flight scan for incoming prompts;
post-flight scan for responses;
RAG and memory scan;
webhook or event intake;
policy decision API;
evidence for SOC, compliance, and incident review.

In this mode Spectorn must be easy to attach beside an existing stack. The customer should not be forced to migrate model routing.

3. Customer buys gateway + protection + memory

This is the strongest mode: Spectorn controls provider routing, policies, keys, protection, memory, and evidence. ASAMM becomes fully visible: the agent receives managed identity, memory provenance, tool-call control, drift/anomaly detection, and audit trail.

Industry scenarios

Banking, finance, HFT

Risks: prompt injection in analytics, PII/PCI leakage, tool calls into payment flows, provider fallback abuse, expensive token consumption.

Controls: AG-2, AI-5, AI-3, AV-2, AO-2.

Actions:

separate keys by product and agent;
deny high-risk models for regulated workflows;
enable spend limits and anomaly alerts;
store evidence for every blocked or downgraded request;
scan RAG and memory for poisoning.

Telecom and NOC agents

Risks: the agent reaches NOC tooling, changes configuration, exposes subscriber data, or calls tools too often.

Controls: AD-2, AI-2, AO-1, AO-2, AV-3.

Actions:

build MCP and tool allowlists;
require approval for destructive network actions;
separate observability from configuration changes;
keep tool-call evidence;
detect drift in command frequency and request patterns.

Government and critical infrastructure

Risks: data residency, sovereign models, air-gapped deployment, supply chain, insider misuse, memory compromise.

Controls: AG-4, AD-1, AI-3, AI-5, AO-4.

Actions:

use self-hosted deployment;
disable external provider fallback;
pin allowed models and providers in tenant policy;
keep evidence locally;
build a separate control plane for memory and data erasure.

Healthcare and PII/PHI

Risks: PHI in prompts, hallucination in recommendations, long-lived patient memory, RAG poisoning in the knowledge base.

Controls: AI-1, AI-3, AV-4, AG-5, AD-3.

Actions:

label context by source and data class;
mask PII/PHI before the provider;
store TTL and erase evidence for memory;
separate clinical support and administrative assistants;
do not let an agent autonomously make medical decisions.

SaaS, support, chatbots

Risks: prompt injection from users, system prompt leakage, CRM exposure, tool calls into billing/support actions, public registration abuse.

Controls: AI-1, AI-2, AV-4, AO-1, AG-2.

Actions:

enable prompt injection and data exfiltration checks;
constrain support-agent tools;
use per-tenant API keys;
log blocked actions without secrets;
return safe fallbacks instead of raw model errors.

DevSecOps and coding agents

Risks: the agent writes an unsafe diff, adds a dependency, exposes secrets in logs, changes deployment config, or ignores tests.

Controls: AI-4, AV-3, AO-3, AO-4, AG-5.

Actions:

require evidence for diff and dependency changes;
run security regression tests before deploy;
block secrets in prompt, log, and output;
test Docker, nginx, and env changes separately;
send high-risk changes to human approval.

MCP and tools

MCP makes agents useful, but it increases blast radius. A minimum baseline:

registry of MCP servers: owner, version, transport, auth, data classes;
signed metadata or pinned config;
tool allowlist per tenant, key, and agent;
private IP egress block when a tool reaches external URLs;
schema hash and evidence for each tool call;
separation of read-only and write/destructive tools;
approval for actions that change money, access, data, or infrastructure.

Memory

Memory is not just "long context". It is a persistent attack surface.

Minimum baseline:

provenance: who wrote it, from which request, with which policy decision;
TTL and expiration;
tenant isolation;
redaction before write;
poisoning scan;
erase evidence;
no automatic trust upgrade for old memory;
separate rules for user memory, org memory, vector memory, and tool-derived memory.

Evidence pack

Industrial buyers need verifiable artifacts, not just a polished report:

model, provider, and alias inventory;
key list and tenant-scoped policy snapshot without secrets;
enabled policies and guardrails;
blocked/allowed decisions for test scenarios;
webhook secret handling;
CORS, origin, TLS, and nginx posture;
Docker ports, networks, volumes, health checks;
security regression results;
ASAMM maturity score;
open high-risk gaps.

Minimum launch checklist

API gateway answers health and OpenAI-compatible endpoints.
Registration is either closed or protected against abuse.
API-key lifecycle works: issuance, revoke, rotation, tenant scope.
Hosted-provider fallback cannot enable without tenant policy.
BYOK is not logged and does not appear in evidence.
SSRF and private IP egress are blocked for provider base URLs and tool URLs.
Dashboard and admin require auth and role checks.
Public metadata does not expose secrets, internal ports, or metrics token.
Nginx, TLS, CORS, and Host header are checked black-box.
Docker does not expose Postgres or Redis publicly.
Memory has at least provenance, TTL, and erase behavior.
Release-evidence is stored beside deployment.

FAQ

Does ASAMM replace OWASP LLM Top 10?

No. OWASP LLM Top 10 describes threat classes. ASAMM organizes maturity: who owns a control, where evidence lives, and how to verify the protection continuously.

Does a gateway customer need to rewrite all code?

No. The baseline changes are base_url, key, and selected model or alias. That is the value of the gateway: multi-provider routing, policy, and protection move into Spectorn.

Why is memory separate?

Because memory outlives a single request. If it is poisoned, leaked, or trusted incorrectly, the attack becomes persistent.

Can ASAMM work for a protection-only customer?

Yes. The main domains become AI, AV, and AO: scan, policy decision, evidence, regression, and incident response. Governance and Design remain the maturity guide.