Method
One spine, three frameworks: how we assess AI agents
Agent security used to be a matter of opinion — ask ten people, get ten answers. Since late 2025 it has page numbers. This is the method we assess against: inventory → scope → gate → log, mapped to the OWASP Agentic AI Top 10, AISVS 1.0, and NIST AI RMF, with a named source behind every number.
Start here
What is an AI agent security assessment?
An AI agent security assessment is a structured review of what your deployed agents can actually do — the tools they can call, the credentials they hold, the actions they can take without a human — measured against published, testable standards. Findings are mapped to the OWASP Agentic AI Top 10, controls are verified against AISVS 1.0, and results are reported in NIST AI RMF language that boards, auditors, and insurers already speak.
In practice the review runs six modules: the agent and tool inventory; identity, credentials, and permissions; prompt-injection and input exposure; memory and RAG integrity; gating and human oversight; and observability and incident readiness. Every finding carries a framework tag, so nothing in the report rests on “trust us” — you can look each item up yourself.
The frameworks aren't interchangeable — they stack. Each layer answers a different question:
Attack level
What goes wrong?
OWASP Agentic AI Top 10 · MITRE ATLAS
Verification level
What do we check?
OWASP AISVS 1.0 — 514 testable requirements
Governance level
How does the organization manage AI risk?
NIST AI RMF (Govern · Map · Measure · Manage) · ISO/IEC 42001
Legal level
What's mandatory?
Colorado AI Act (live since February 2026) · EU AI Act (high-risk obligations December 2, 2027) · sectoral rules
The assessment logic reads down that stack: find weaknesses in Agentic Top 10 terms, verify controls against AISVS requirements, report posture in NIST AI RMF language the board recognizes, and flag legal obligations where exposure exists. The near-term legal clock is domestic — the Colorado AI Act has been live since February 2026 and other states are following — while EU AI Act high-risk obligations land December 2, 2027, and enterprise customers are already pushing both into vendor due-diligence questionnaires ahead of the deadlines.
What that produces, scope and pricing included, is on the Agent Security Assessment page.
The method
How do you secure AI agents in production?
Inventory what your agents can do, scope their credentials to the task, gate irreversible and high-blast-radius actions behind a human, and log everything so you can prove what happened. That four-step spine is where the OWASP Agentic AI Top 10, AISVS 1.0, and NIST AI RMF converge from different directions. The frameworks add the rigor and the receipts; the spine is what your team applies.
None of this is new security philosophy — least privilege, identity, human oversight, and audit trails predate AI by decades. What's new is applying them to software that plans and acts on its own. Here is each clause of the spine, with the reasoning and the risks it counters:
Step 1
Inventory
You can't secure what you haven't enumerated.
Every agent, MCP server, tool, credential, memory store, and agent-to-agent channel — enumerated, with an owner. Most deployments fail here first: the tool list in the config is not the tool list in production. The inventory is where supply-chain review starts, because you can't vet a component you don't know you're running.
Step 2
Scope
Credentials sized to the task, not the convenience.
Per-agent, per-tool least privilege; short-lived credentials; write access to memory and vector stores treated as a privilege of its own. An agent that can't call a tool can't be tricked into misusing it — scoping shrinks the blast radius before any attack starts.
Step 3
Gate
Irreversible, high-blast-radius actions get a human. Reversible, contained actions run.
The point is not to approve everything — that recreates the bottleneck agents were meant to remove, and trains approvers to rubber-stamp. The point is deciding deliberately which actions deserve a human, and making that approval meaningful: real context, real authority to say no.
Step 4
Log
If you can't reconstruct what an agent did, you can't run it in production.
Attribution per agent and per version, decision context, tool calls with arguments and outcomes. The protocol layer gives you no standard audit trail — you have to build the receipts. Logging is what turns drift, cascade, and rogue-agent scenarios from invisible to detectable.
The frameworks converge on this spine from three directions: the Agentic AI Top 10 names the failures, AISVS supplies the checks, and NIST AI RMF gives leadership the management language. The full mapping is in the table below.
The threat model
What is the OWASP Agentic Top 10?
The OWASP Top 10 for Agentic Applications (December 2025) is the industry-consensus list of the ten most serious security risks in systems where AI can plan, decide, and act — ASI01 through ASI10. It was peer-reviewed by more than a hundred experts, with reviewers from NIST, Microsoft's AI red team, and the Alan Turing Institute, and every entry responds to failure patterns already observed in production.
Released December 9, 2025 by the OWASP GenAI Security Project, the Top 10 for Agentic Applications is the first industry-consensus threat model for software that doesn't just answer — it acts. That distinction is the whole point: a chatbot that fails gives someone a wrong answer, while an agent that fails takes a wrong action, with real credentials, on real systems. The list is already cited inside major vendors' own agent-security frameworks.
If you run agents, this list is your threat model whether or not you've read it — your attackers have. We use it as the findings taxonomy in every review: each finding carries an ASI tag, so your remediation backlog speaks the same language as the standard. All ten, with what each looks like in practice, are in the mapping below. Prefer the long-form version? The frameworks explainer walks through all ten in plain language — and answers which framework to assess against first.
The verification standard
What is AISVS and who needs it?
AISVS — the OWASP AI Security Verification Standard, v1.0, released June 2026 — is the testable half of AI security: 514 'verify that…' requirements across 14 chapters, each at verification level 1, 2, or 3. Any organization running AI agents or MCP servers in production needs it, because it turns 'we take security seriously' into statements someone can check. Most production systems should target Level 2.
A threat list tells you what to fear; it doesn't tell you what to verify. AISVS closes that gap. It was built by the lineage behind ASVS — the standard web-application auditors have used for years — and it follows the same discipline: if you can't check it, it doesn't belong in the standard. The specificity is the value. One example: MCP authorization must be validated on everytool call, not once per session. That's a requirement you can hand to an engineer on Monday and audit on Friday.
Fourteen chapters cover the AI layer end to end — training data, input validation, model lifecycle, infrastructure, access control, supply chain, model behavior, memory and vector databases, agentic orchestration, MCP security, adversarial robustness, privacy, monitoring, and human oversight. Six of them are the working core of a mid-market agent review: C05 access control, C08 memory, C09 agentic orchestration, C10 MCP security, C13 monitoring & logging, and C14 human oversight.
Deliberately, AISVS covers only the AI layer — general application security stays with ASVS, and infrastructure hardening stays with the CIS benchmarks and NIST 800-53. A review that claims one standard covers everything is a review to be suspicious of.
The mapping
Ten risks, one spine, checkable controls
Every OWASP Agentic AI Top 10 risk, the failure pattern behind it, the spine stage that counters it, the AISVS 1.0 chapters that verify the counter, and the NIST AI RMF function it reports under.
| Risk | Failure pattern | Spine stage | Verified against (AISVS 1.0) | Reported under (NIST AI RMF) |
|---|---|---|---|---|
| ASI01Agent Goal Hijack | Hidden instructions in ordinary content redirect the agent's objectives. | Gate + Log | C02 input validation · C07 model behavior | Measure · Manage |
| ASI02Tool Misuse & Exploitation | Legitimate tools get bent to destructive use. | Scope + Gate | C09 orchestration — per-action authorization | Manage |
| ASI03Identity & Privilege Abuse | Agents hold broader credentials than the task needs. | Scope | C05 access control | Govern · Map |
| ASI04Agentic Supply Chain | Poisoned servers, tools, or skills load at runtime. | Inventory | C06 model supply chain · C10 MCP security | Map |
| ASI05Unexpected Code Execution | Natural-language paths become code-execution paths. | Gate | C09 tool sandboxing · C04 infrastructure | Manage |
| ASI06Memory & Context Poisoning | Seeded memory reshapes behavior long after the session ends. | Scope + Log | C08 memory, embeddings & vector databases | Measure |
| ASI07Insecure Inter-Agent Communication | Spoofed agent-to-agent messages misdirect clusters. | Inventory + Scope | C09 agentic orchestration | Map · Measure |
| ASI08Cascading Failures | One false signal propagates through automated pipelines. | Gate + Log | C13 monitoring & anomaly detection | Measure |
| ASI09Human-Agent Trust Exploitation | Confident, polished output misleads the human approver. | Gate | C14 human oversight | Govern · Manage |
| ASI10Rogue Agents | Compromised or drifting agents keep operating. | Log + Inventory | C13 monitoring · C09 orchestration | Measure · Manage |
This table is the method in one screen: findings named in ASI terms, controls verified as AISVS “verify that” checks, posture reported Govern / Map / Measure / Manage. The frameworks are open — take the mapping and use it. What a review adds is the judgment: which findings are real in your deployment, and in what order to fix them.
The protocol layer
Are MCP servers secure?
Not by default. The MCP specification delegates authentication to the transport layer and defines no per-tool authorization, no standard agent identity, and no standard audit-log format — four structural gaps every deployment inherits. Independent audits bear this out: 71% of 100 audited public MCP servers graded F and zero received an A (AgentsID, 2026), and an academic study of 1,899 servers found tool-poisoning patterns in roughly 5% (Hasan et al., 2025).
The four gaps are protocol-level facts, not vendor failings — which is exactly why they matter: every MCP deployment inherits them on day one, before a single config is written. Four sentences, no statistics required. Quote them in your next architecture review:
Structural gap 1 of 4
“MCP delegates authentication to the transport layer — nothing in the protocol itself checks who is calling.”
Structural gap 2 of 4
“There is no per-tool authorization. A connected agent can typically call every tool a server exposes.”
Structural gap 3 of 4
“There is no standard agent identity — nothing attests which agent, or which version of it, performed an action.”
Structural gap 4 of 4
“There is no standard audit-log format. Reconstructing what your agents did after an incident is archaeology.”
What independent audits found
~78%
false-positive rate on MCP tool-description scans
Source: An independent audit found ~78% of YARA detections on MCP tool descriptions were false positives (AppSec Santa audit, April 2026).
71%
of audited public MCP servers graded F — zero received an A
Source: AgentsID 100-package audit, 2026. Every vendor-maintained tool-exposing server in the sample failed.
~5%
of MCP servers carried tool-poisoning patterns
Source: Hasan et al., academic study of 1,899 servers, 2025.
The supporting numbers point the same direction: a 2026 GitGuardian sweep found 24,008 secrets sitting in public MCP configurations, 2,117 of them still valid, and Trend Micro tracked exposed, authentication-free public MCP servers growing from 492 to 1,467 across 2025–26. None of this means “don't use MCP.” It means MCP deployments need the security work the protocol doesn't do for them — inventory, scoping, gating, and logging are yours to add.
The failure modes
What causes AI agent security incidents?
AI agent security incidents follow a short list of repeating patterns — goal hijacking through untrusted content, over-scoped credentials, tool misuse, memory poisoning, and compromised components in the agent supply chain — catalogued as ASI01–ASI10 in the OWASP Agentic AI Top 10. Every entry on that list responds to incidents already observed in the wild. The common thread: agents hold real credentials and act at machine speed, so one manipulated input becomes real actions on real systems.
The mechanism is worth being precise about. Prompt injection in a chatbot yields a bad answer; prompt injection in an agent yields a bad action — the blast radius is the difference. Chain that with credentials scoped to convenience rather than task, components adopted at runtime without vetting, and no per-step human review, and a single manipulated input can become a sequence of privileged operations before anyone looks up.
The honest engineering posture is containment, not prevention: you will not filter every hostile input, so you bound what a hijacked agent can do (Scope), require a human where actions are irreversible (Gate), and keep receipts that make compromise detectable (Log). That is why the spine leads with inventory — every other control depends on knowing what's running.
The method is public. The judgment is the service.
Everything on this page — the frameworks, the spine, the mapping — is open, and you can apply it yourself. If you'd rather have it applied by someone who does this every week: the Agent Security Snapshot baselines your deployment against this method in five business days for $1,500, and the full Assessment goes as deep as your architecture does.
This method is maintained by Peter Kwidzinski, Fellow-Level Security Architect — two decades in platform security at semiconductor leaders Intel and AMD, reaching Fellow, the top rung of the technical ladder — and a founding contributor to Caliptra, the open-source hardware root of trust. Least privilege, identity, attestation, audit trails: the spine of this method is the spine of platform security, applied to agents.