research/owasp/agentic-top10-reading.md
Reading the OWASP® Top 10 for Agentic Applications 2026
A close reading for c123's framework detail page and the c125 tour. Source: owasp-top10-agentic-applications-2026.pdf (OWASP GenAI Security Project, Agentic Security Initiative, 9 Dec 2025, CC BY-SA 4.0). Page numbers are printed / PDF. Mitigations are paraphrased in our words and numbered as in the paper, so a UI can point at "ASI04 mitigation 8" and open the PDF at the right page.
1. What kind of document this is
- A risk taxonomy, not a control framework. Ten entries, each with the same five parts: Description, Common Examples, Example Attack Scenarios, Prevention and Mitigation Guidelines, References. Nothing to certify against. A customer uses it as threat-model scaffolding and a questionnaire vocabulary ("how do you address ASI02?").
- A compass over a larger library. The letter (p.6–7 / 7–8) says the Top 10 condenses the Agentic AI – Threats and Mitigations guide (T1–T17), and each entry names its T-codes. Appendix A maps every entry to the LLM Top 10 2025 IDs, the T-codes and AIVSS core risks. Note the LLM cross-references use 2025 numbering (e.g. "LLM06:2025 Excessive Agency", which is LLM03 in the 2026 edition). The detail page should show the cited ID as written and the 2026 equivalent beside it.
- Two ideas in the letter frame everything (p.7 / 8):
- Least Agency, extending least privilege: don't give autonomy where it adds nothing, because every unneeded autonomous step is attack surface.
- Observability is non-negotiable: without seeing what agents do, why, and which tools they invoke, small issues become system-wide. This is Qpoint's opening line in the tour, and it's OWASP's sentence, not ours.
- A map ("At a Glance", p.8 / 9): Inputs (user prompts, APIs, external agents) → Integration/Processing (policy & governance, agent, agents, connected data/RAG, memory) → Outputs (human-in-the-loop, tools, APIs/resources, external agents), with each ASI placed where it lives. ASI01/03/09 sit at the input and human edge; ASI02 at tools; ASI07 between agents; ASI06 at memory/RAG; ASI04/05/08 underneath everything.
- Appendices worth surfacing: A mapping matrix (p.39 / 40), B CycloneDX/AIBOM (p.41 / 42: "what's in my AI system" vs "how can it behave unsafely"), C Non-Human Identities Top 10 mapping (p.42 / 43), D Exploits & Incidents tracker (p.44 / 45: 24 named, dated incidents, each tagged with ASI IDs, e.g. the postmark-mcp impersonation, the Amazon Q v1.84.0 poisoned prompt, Framelink Figma MCP RCE, a run of Cursor CVEs, EchoLeak, Replit's deleted production DB).
- Small defects to know before quoting: a garbled heading in ASI02 scenario 4 (font-encoding glitch; it reads as tool chaining to exfiltrate a CRM list), "AS01"/"AS04" typos in ASI10, ASI07's AIVSS cell looks swapped with ASI06's, and the license block's attribution example names the wrong asset.
2. The boundary rules (the paper's real contribution)
Every entry says what it is not. Taken together they form a grammar that the tour can teach:
| Question the paper asks | Entry |
|---|---|
| Was the agent's goal or plan redirected (now, by input)? | ASI01 Goal Hijack |
| Did it use a legitimate tool, within its rights, in a harmful way? | ASI02 Tool Misuse |
| Did it act with rights it shouldn't have (inherited, cached, delegated, spoofed)? | ASI03 Identity & Privilege |
| Was a component (tool, MCP server, model, prompt, peer agent, registry) bad at the source? | ASI04 Supply Chain |
| Did text become executed code on a host? | ASI05 Code Execution |
| Was stored context (memory, RAG, summaries) corrupted, persisting across sessions? | ASI06 Memory & Context |
| Were messages between agents intercepted, spoofed, replayed or downgraded? | ASI07 Inter-Agent Comms |
| Did one fault spread across agents, sessions or tenants? (origin is filed elsewhere) | ASI08 Cascading Failures |
| Was a human misled into doing the final, audited act? | ASI09 Human-Agent Trust |
| Has an agent's behavior diverged from its purpose, after whatever started it? | ASI10 Rogue Agents |
Three of these are about time and spread, which maps onto views Qpoint already has: an origin is an event (first-seen, a finding), propagation is fleet fan-out (how many endpoints, users, agents touched it), behavior is drift over a timeline (baseline vs now).
3. Mitigation primitives (why one policy covers many risks)
The ~85 mitigations reduce to a dozen recurring primitives. Qpoint governs primitives, not risks, which is why its policy map is many-to-many.
| Primitive | Appears in | Qpoint |
|---|---|---|
| Inventory / BOM of AI components | 04#1, 10#6, App. B | Observed: providers, models, harnesses, MCP servers, skills, tools, workspaces |
| Allow-list and pin by name/version/hash | 02#7, 04#2, 04#7, 05#6, 07#6 | Enforced: P-TOOL-ALLOW, P-MCP, P-PROVENANCE |
| Human approval for high-impact actions | 01#2, 01#4, 02#2, 03#4, 05#6, 06#7, 08#5, 09#1, 10#7 | Enforced: P-TOOL-APPROVAL |
| An external policy point the agent doesn't control | 02#4, 03#3, 08#3, 08#4 | Enforced: Qpoint runs on the endpoint, outside the agent's process |
| Sandbox, no root, filesystem and egress limits | 02#3, 04#3, 05#4, 05#5, 08#2, 10#2 | Enforced/Observed: P-SANDBOX, P-NO-ROOT, P-FILES, P-DATA-BOUNDARY |
| Least privilege, short-lived scoped credentials | 01#2, 02#1, 02#6, 03#1, 03#5, 03#7, 08#3, 10#6 | Observed (which credential each harness presents) · issuance is outside |
| Keep secrets and sensitive data out of context | 03 ex.2, 06#2, 09#3 | Enforced: P-CREDENTIALS, P-SENS-DETECT, P-SENS-SANITIZE |
| Validate untrusted input and tool output | 01#1, 01#6, 05#1, 07#2 | Observed: P-PROMPT-INSPECT, P-OUTPUT (partial) |
| Budgets, rate limits, circuit breakers | 02#5, 08#6, 08#7 | Enforced: P-SPEND; volume seen on Cost |
| Encrypted, authenticated channels | 04#5, 06#1, 07#1, 07#4 | Observed/Enforced: P-TRANSPORT, weak-TLS alerts |
| Behavioral baseline and drift detection | 01#7, 02#8, 04#6, 08#8, 09#9, 10#3, 10#5 | Observed: per-agent tools and destinations over time |
| Immutable logs of tool calls and actions | 01#7, 02#8, 08#10, 09#2, 10#1 | Evidenced: P-TELEMETRY, sessions, Policy Config history |
| Kill switch, revocation, quarantine | 04#8, 10#4 | Enforced: a block policy applied fleet-wide |
| Red-teaming, replay, rollback | 01#8, 06#7, 08#9 | Outside — except 08#9, see below |
The paper describes several things Qpoint already is. Use these sparingly and exactly in the tour:
- ASI02 #4 and ASI08 #4: a pre-execution Policy Enforcement Point separate from the planner.
- ASI04 #8: a supply-chain kill switch that disables a tool or connection across all deployments.
- ASI08 #9: re-run recorded agent actions against a proposed policy before expanding it. That is Change impact: staging a policy at Observe and computing it against recorded activity (c118/c121).
- ASI08 example 6: governance drift, where oversight weakens and policy relaxations spread. Policy Config history makes it visible.
- ASI02 scenario 6: misuse by trusted binaries under valid credentials, which EDR doesn't see. AI-aware observation of tool chains does.
4. The ten entries
Tags on each mitigation, using c123's working states: Enforced (a Qpoint policy can stop it) · Observed (Qpoint shows it) · Evidenced (Qpoint's records prove it was done) · Outside (yours: design, build, IdP, people). "Idea" marks a signal Qpoint doesn't collect today.
ASI01 Agent Goal Hijack — p.9 / 10
For you: anything your agents read (a web page, an email, a calendar invite, a doc) can carry instructions that quietly change what the agent is trying to do. Boundary: direct manipulation of goals or plan; persistent memory corruption is ASI06, drift with no attacker is ASI10. Agentic evolution of LLM01 (prompt injection) + LLM06 (excessive agency). T6, T7. Incidents: EchoLeak (zero-click M365 Copilot), Operator web injection, AgentFlayer, ForcedLeak (Agentforce), GitHub public-issue hijack, Gemini Trifecta.
| # | Mitigation (our words) | Qpoint |
|---|---|---|
| 1 | Treat every natural-language input as untrusted; run injection safeguards before it can steer planning | Observed — P-PROMPT-INSPECT flags known patterns in captured content |
| 2 | Least privilege for tools; human approval for high-impact or goal-changing actions | Enforced — P-TOOL-ALLOW, P-TOOL-APPROVAL |
| 3 | Lock system prompts; goal changes go through config management and approval | Outside · Idea: fingerprint system prompts on the wire, flag changes |
| 4 | Check intent at run time; pause or block on goal shift; record for audit | Enforced at the approval gate · Evidenced |
| 5 | "Intent capsule": bind goal and constraints to each cycle in a signed envelope | Outside (build-time pattern) |
| 6 | Sanitize every connected source (RAG, email, calendar, files, browsing, peer agents) | Observed — which sources and connectors feed each agent |
| 7 | Log everything; baseline goal state and tool-use patterns; alert on deviation | Observed + Evidenced — P-TELEMETRY, tool sequences per session |
| 8 | Red-team goal override; verify rollback | Outside → link the Red Teaming Manual |
| 9 | Put agents in the insider-threat program | Evidenced — every session attributed to a person and device |
Fit: partial. Qpoint can't see intent; it sees what comes in and what the agent does next, and can gate the consequential step.
ASI02 Tool Misuse & Exploitation — p.12 / 13
For you: an agent can do real damage with tools it's allowed to use: send the mail, delete the rows, call the paid API ten thousand times. Boundary: misuse within granted rights; escalation is ASI03, code execution ASI05, a tool bad at the source ASI04. Builds on LLM06:2025. T2 (+T4, T16). Incidents: Framelink Figma MCP, postmark-mcp, ForcedLeak, Amazon Q prompt poisoning, EchoLeak; DNS exfiltration through an auto-approved ping tool (Amazon Q Developer).
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Per-tool least-privilege profiles (scope, max rate, egress allow-list) | Enforced — P-TOOL-ALLOW, P-DATA-BOUNDARY |
| 2 | Authenticate each invocation; human confirmation for destructive actions, with a dry-run preview | Enforced — P-TOOL-APPROVAL |
| 3 | Sandboxes and egress allow-lists; deny everything else | Enforced/Observed — P-SANDBOX, P-PROVIDERS |
| 4 | An "intent gate": a policy point that validates arguments, enforces rate limits, audits drift | Enforced — Qpoint is that point for tool calls and egress; semantic intent is partial (P-OUTPUT) |
| 5 | Tool budgets with automatic throttle or revoke | Enforced — P-SPEND · Observed on Cost |
| 6 | Just-in-time, session-bound credentials | Observed (credential age and reuse on Identity) · issuance Outside |
| 7 | Fully qualified tool names and version pins; fail closed on ambiguity | Enforced — P-PROVENANCE · Idea: look-alike name flag (report vs report_finance) |
| 8 | Immutable logs of every invocation; watch rates and chains like DB-read → external send | Evidenced + Observed · Idea: chain patterns as a finding type |
Fit: strongest. This is the entry the tour should spend time on.
ASI03 Identity & Privilege Abuse — p.15 / 16
For you: agents act with somebody's credentials. When nobody can say whose, or the agent keeps them around, rights leak from one task, user or agent to another. Boundary: acting with rights it shouldn't have; using its own rights badly is ASI02. Maps 1:1 to T3; LLM01/02/06:2025. The paper names the root cause as an attribution gap: an agent with no governed identity of its own. Incidents: Copilot Studio public-by-default agents, Heroku MCP ownership hijack, Operator, A2A agent-in-the-middle.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Task-scoped, time-bound permissions; per-agent identities | Observed — Identity ledger: the credential each harness presents, shared or long-lived keys |
| 2 | Isolate identities and context per session; wipe state | Outside · partly Enforced via P-CREDENTIALS (keeps secrets out of model context, the "memory-based privilege retention" example) |
| 3 | Re-authorize each privileged step with a central policy engine | Enforced — per-call policy at the endpoint |
| 4 | Human approval for escalation and irreversible actions | Enforced — P-TOOL-APPROVAL |
| 5 | Bind OAuth tokens to a signed intent | Outside |
| 6 | Use agentic IAM platforms (Entra, Bedrock Agents, Agentforce…) | Outside · integration candidate |
| 7 | Bind permissions to subject, resource, purpose, duration; revoke on idle or anomaly | Outside |
| 8 | Detect delegated and transitive permissions in multi-agent chains | Outside today · Idea: sub-agent and delegation lineage |
| 9 | Detect new scopes or token reuse outside original intent; device-code phishing | Observed, partly — a credential seen from an unexpected harness or device; P-ACCT, P-ENTERPRISE |
Fit: partial. Qpoint closes the attribution gap observationally (every call tied to a person, device and harness) and catches the crude cases (personal accounts, shared keys, secrets in prompts). Issuance and delegation live in the IdP.
ASI04 Agentic Supply Chain Vulnerabilities — p.18 / 19
For you: your agents assemble themselves at run time from other people's parts (MCP servers, skills, prompt templates, models, peer agents) and any of them can be malicious, compromised or an impostor. Boundary: the component is bad at the source; runtime tampering with a good tool's interface is ASI02. Extends LLM03:2025 from static manifests to a live supply chain. T17 (+T2, T11, T12, T13, T16). Incidents: postmark-mcp impersonation (first in-the-wild malicious MCP server), a backdoored MCP package on npm, Amazon Q v1.84.0, GitHub MCP descriptor poisoning, AgentSmith prompt-hub, poisoned nx release auto-installed by coding agents, Cursor CLI project config.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Provenance; SBOM/AIBOM; an inventory of AI components; curated registries; block untrusted sources | Observed — the inventory is an observed AIBOM · Enforced — P-MCP |
| 2 | Allow-list and pin; scan for typosquats; reject unverified | Enforced — P-MCP, P-PROVENANCE · Idea: look-alike names |
| 3 | Sandboxed containers for sensitive agents | Observed — P-SANDBOX |
| 4 | Prompts and orchestration under version control | Outside |
| 5 | Mutual auth, signed inter-agent messages | Observed — P-TRANSPORT (partly) |
| 6 | Re-check hashes and lineage at run time; watch behavior | Observed — first-seen, version drift on MCP servers, skills, harnesses |
| 7 | Pin by hash; staged rollout; auto-rollback on drift | Enforced — P-PROVENANCE · Qpoint's own Observe → Enforce staging mirrors "staged rollout" |
| 8 | Kill switch: disable a tool, prompt or connection everywhere at once | Enforced — a block policy, fleet-wide |
| 9 | Zero-trust application design | Outside |
Fit: strong. Appendix B's question, "what components and tools are in my AI system?", is the Inventory section of the dashboard. Idea: check Appendix D's named components against the inventory ("postmark-mcp: not in your fleet").
ASI05 Unexpected Code Execution (RCE) — p.21 / 22
For you: coding agents write and run code on real machines, so a sentence in a prompt can become a shell command on a laptop or a server. Boundary: text becomes execution on a host; ordinary tool misuse is ASI02. Builds on LLM01 + LLM05:2025. T11. Incidents: most of Appendix D: Cursor (config overwrite, workspace file, CLI file-protection bypass), Framelink Figma MCP, VS Code agentic workflows, Gemini CLI wiping a directory, Replit, Flowise, ToolShell.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Sanitize generated code (LLM05) | Enforced, partly — P-OUTPUT |
| 2 | No direct agent-to-production; pre-production checks for vibe coding | Observed — sessions reaching production hosts or environments |
| 3 | Ban eval in production agents | Outside |
| 4 | Never run as root; sandbox; confine the filesystem; log file diffs on critical paths | Enforced — P-NO-ROOT, P-SANDBOX, P-FILES · Observed — sensitive file/path movement (Data Protection) |
| 5 | Per-session environments; separate generation from execution | Outside |
| 6 | Human approval for elevated runs; the auto-run allow-list under version control | Enforced — P-TOOL-APPROVAL, P-TOOL-ALLOW · Evidenced — Policy Config history is that version control |
| 7 | Static scans, runtime monitoring, log every generation and run | Evidenced — sessions; process events where captured |
Fit: partial→strong for host guardrails, depending on process-lineage capture.
ASI06 Memory & Context Poisoning — p.24 / 25
For you: what an agent remembers (chat history, summaries, a vector store) can be seeded with lies that keep steering it long after the attacker has gone. Boundary: persistent corruption of stored context; a one-shot prompt is LLM01, the spread afterwards is ASI08. LLM01/04/08:2025. T1 (+T4, T6, T12). Incidents: Gemini long-term memory, ChatGPT false memories, PoisonedRAG, AgentPoison, EchoLeak.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Encrypt in transit and at rest; least-privilege access | Observed — in transit (P-TRANSPORT) |
| 2 | Scan memory writes for malicious or sensitive content before commit | Enforced, partly — P-SENS-DETECT/SANITIZE on what crosses the wire to memory and RAG APIs |
| 3 | Segment memory by user and domain | Outside |
| 4 | Only authenticated, curated sources; minimal retention | Observed — which memory, RAG and vector endpoints each agent uses |
| 5 | Source attribution; flag suspicious update frequencies | Observed, partly — write volume to memory endpoints · Idea |
| 6 | Don't re-ingest the agent's own outputs as trusted memory | Outside |
| 7 | Adversarial tests, snapshots, rollback; per-tenant namespaces | Outside → Red Teaming Manual |
| 8 | Expire unverified memory | Outside |
| 9 | Weight retrieval by trust and tenancy | Outside |
Fit: weak. Memory lives inside the app. Qpoint can say where it lives and what sensitive data went into it.
ASI07 Insecure Inter-Agent Communication — p.27 / 28
For you: agents talk to other agents and to MCP endpoints; if those conversations aren't encrypted and authenticated, someone else can join them. Boundary: messages in flight; credential misuse is ASI03, stored knowledge ASI06. LLM02/06:2025. T12, T16. Incidents: MCP OAuth response exploit (Cursor), postmark-mcp, Copilot Studio, A2A agent-card spoofing, GitHub public-issue hijack.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | End-to-end encryption, mutual auth, certificate pinning | Observed/Enforced — P-TRANSPORT; weak-TLS alerts |
| 2 | Sign messages; NL-aware sanitization of hidden instructions | Outside · Observed, partly — P-PROMPT-INSPECT on tool responses |
| 3 | Anti-replay: nonces, session IDs, timestamps | Outside |
| 4 | Disable weak or legacy modes; enforce version and capability "at gateways or middleware" | Enforced — P-TRANSPORT blocks plaintext and downgraded channels |
| 5 | Pad and smooth traffic against metadata inference | Outside |
| 6 | Pin protocol versions (MCP, A2A, gRPC); reject downgrades | Observed — transport per MCP server · Idea: MCP protocol version |
| 7 | Authenticate discovery; watch anomalous routing | Observed, partly — new destinations |
| 8 | Attested registries; signed agent cards | Outside |
| 9 | Typed, versioned message schemas | Outside |
Fit: partial: transport yes, message integrity no. A2A traffic isn't classified today (Idea).
ASI08 Cascading Failures — p.30 / 31
For you: one bad part (a hallucination, a poisoned memory, a compromised tool) can travel through every agent that trusts it faster than a person can follow. Boundary: propagation only; file the origin under ASI04/06/07. The paper gives detection hooks: rapid fan-out, cross-tenant spread, oscillating retries, queue storms, repeated identical intents. T5, T8. It also admits a residual risk: fault speed outruns human oversight.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Zero-trust fault tolerance | Outside |
| 2 | Isolation and trust boundaries: sandbox, segmentation, scoped APIs | Enforced — P-SANDBOX, P-DATA-BOUNDARY, policies scoped by team and device group |
| 3 | Just-in-time tool access; check each high-impact call against policy-as-code | Enforced |
| 4 | Independent policy enforcement, separate from planning | Enforced — Qpoint sits outside the agent |
| 5 | Human gates before outputs propagate | Enforced — P-TOOL-APPROVAL |
| 6 | Rate limits; throttle fast-spreading commands | Observed · Enforced — P-SPEND |
| 7 | Blast-radius guardrails: quotas, circuit breakers | Enforced, partly — P-SPEND · Idea: blast-radius view |
| 8 | Behavioral and governance drift detection | Observed + Evidenced — Policy Config history shows relaxations |
| 9 | Replay recorded actions against a proposed policy before expanding it | Enforced-adjacent — Change impact at Observe |
| 10 | Tamper-evident logs; lineage for every propagated action | Evidenced — sessions (tamper-evidence not claimed) |
Fit: partial, and better than the dossier's "weak": the fleet view is exactly where fan-out shows up.
ASI09 Human-Agent Trust Exploitation — p.33 / 34
For you: people trust a fluent, confident agent, and an attacker can use that trust to get a human to make the final, approved, logged mistake. Boundary: human over-reliance; agent deviation is ASI10. LLM01/05/06/09:2025. T7, T8, T10. Incidents: Replit (false outputs hiding a deleted DB), Copilot/Cursor suggestions with backdoors, M365 Copilot steering a wire transfer.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Multi-step approval before sensitive data or risky actions | Enforced — P-TOOL-APPROVAL |
| 2 | Immutable logs of queries and actions | Evidenced — P-TELEMETRY |
| 3 | Watch sensitive data exposed in conversations and agent connections | Observed — Data Protection |
| 4 | Let users flag suspicious agent behavior | Outside · Idea: "flag this session" |
| 5 | Adaptive trust: autonomy and oversight scaled to risk; training | Outside (Observe vs Enforce per team is a coarse version) |
| 6 | Provenance on recommendations; block actions beyond declared scope | Enforced, partly |
| 7 | Separate preview from effect | Outside (agent UX) — Qpoint's own Policy Config draft follows it |
| 8 | Human-factors safeguards: risk cues, no persuasive language | Outside |
| 9 | Plan-divergence: compare action sequences to baselines | Observed, partly · Idea |
Fit: mostly outside, but Qpoint holds the record and can show whether approvers actually review (Idea: approval health).
ASI10 Rogue Agents — p.36 / 37
For you: an agent can drift from what it was set up to do (keep exfiltrating, copy itself, game its metric) while each step looks legitimate. Boundary: loss of behavioral integrity after whatever started it. LLM02/09:2025. T13 (+T14, T15). Incidents: Replit, A2A agent-in-the-middle.
| # | Mitigation | Qpoint |
|---|---|---|
| 1 | Immutable, signed logs of actions, tool calls, inter-agent messages | Evidenced |
| 2 | Trust zones; restricted environments; least-privilege API scopes | Enforced, partly — P-SANDBOX, scoped policies |
| 3 | Behavioral detection; abnormal action counts; watchdogs | Observed |
| 4 | Kill switches and credential revocation; quarantine | Enforced — block the agent, harness or server · revocation Outside |
| 5 | Signed behavioral manifests (expected tools, capabilities, goals), deviations flagged | Enforced/Observed — the allow-list is an unsigned manifest; deviations become findings |
| 6 | Periodic attestation; signed BOM for prompts and tools | Observed — the observed BOM |
| 7 | Reintegrate only after fresh verification and human approval | Evidenced — finding resolution |
Fit: partial. The tour beat is "expected vs observed, and the switch".
5. Fit summary (for the fixture)
| Entry | Fit | Mapped policies (lab fixture IDs) | Procedural? |
|---|---|---|---|
| ASI01 Goal Hijack | Partial — detect and contain; intent is invisible on the wire | P-PROMPT-INSPECT, P-TOOL-APPROVAL, P-TOOL-ALLOW, P-TELEMETRY | yes |
| ASI02 Tool Misuse | Addressable — strongest fit | P-TOOL-ALLOW, P-TOOL-APPROVAL, P-SANDBOX, P-SPEND, P-OUTPUT, P-TELEMETRY | no |
| ASI03 Identity & Privilege | Partial — attribution and credential hygiene; issuance is the IdP's | P-CREDENTIALS, P-ACCT, P-ENTERPRISE, P-TOOL-APPROVAL | yes |
| ASI04 Supply Chain | Addressable — inventory, pinning, kill switch | P-MCP, P-PROVENANCE, P-PROVIDERS | yes |
| ASI05 Code Execution | Partial — host guardrails; code review is yours | P-NO-ROOT, P-SANDBOX, P-FILES, P-OUTPUT, P-TOOL-APPROVAL | yes |
| ASI06 Memory & Context | Mostly outside — Qpoint sees what crosses the wire | P-SENS-DETECT, P-SENS-SANITIZE, P-DATA-BOUNDARY | yes |
| ASI07 Inter-Agent Comms | Partial — transport, not message integrity | P-TRANSPORT, P-PROMPT-INSPECT | yes |
| ASI08 Cascading Failures | Partial — fan-out signals, independent enforcement, replay before enforce | P-SPEND, P-TOOL-APPROVAL, P-TELEMETRY | yes |
| ASI09 Human-Agent Trust | Mostly outside — Qpoint keeps the record | P-TOOL-APPROVAL, P-TELEMETRY, P-SENS-DETECT | yes |
| ASI10 Rogue Agents | Partial — expected vs observed, and the switch | P-TOOL-ALLOW, P-MCP, P-TELEMETRY | yes |
P-TOOL-APPROVAL is mapped under six entries and P-TELEMETRY under five: the "one policy, many risks" moment. (Counting mitigations rather than mappings, human approval shows up in eight entries; see §3.) In the fixture since 2026-10-27 as owasp-agentic, untracked.
6. Signals Qpoint would need (product feedback)
From the Idea tags, in rough order of payoff:
- MCP tool-descriptor drift: hash a server's tool list at approval; flag when it changes (tool poisoning, ASI02 sc.1; descriptor injection, ASI04 ex.2).
- Blast radius on any inventory item: users, devices, agents and sessions that touched it, with the block action beside it (ASI04 #8, ASI08, ASI10 #4).
- Known-incident check: Appendix D's named components and versions against the inventory.
- Look-alike names for MCP servers, skills and tools (typosquatting, ASI02 #7, ASI04 #2).
- Approval health: approval rate and time-to-approve per approver (automation bias, ASI09; governance drift, ASI08 ex.6).
- Expected vs observed per agent (behavioral manifest, ASI10 #5).
- Sub-agent and delegation lineage (ASI03 #8); A2A traffic and agent cards (ASI07); DNS (the ping exfiltration in ASI02 sc.7); system-prompt fingerprints (ASI01 #3); memory-endpoint classification (ASI06).