The addressable tour: where Qpoint is strongest against the OWASP® Agentic Top 10

Mark, 2026-10-27 (prompt): design the tour around the parts of the Top 10 Qpoint can most address. Source contamination becomes source health. MCP concerns become how we watch, and how you tune it to your organization.

This replaces the ten-stop walk in owasp-agentic-tour.md §3 as the tour we build first. That file keeps the per-risk map (§1), the stop anatomy Mark liked (§3), the shared content record (§4) and the attribution footer (§5). The concept canvas has the new stops: https://claude.ai/artifact/V4qJ4c8sgfuTZv1nvcfmy1.

The shift

v1 walked the paper's ten risks in order. This tour is organized by the customer's concern, and it only goes where Qpoint can watch and act. Each stop names the risks and numbered mitigations it answers, so the paper is still the spine; it's just not the agenda. Risks Qpoint mostly can't address (ASI06 memory internals, ASI09 human trust) get one honest line in the closing step and a link to the paper, not a stop.

Every stop has four beats (Drill added by Mark, 2026-10-27; see § The Drill beat):

1. Watch: what Qpoint sees, on the real page, with the region ringed.
2. Tune: how you set it to suit your organization: which teams, how strict, what's allowed, until when. Shown in the Policy Config draft with Change impact.
3. Drill: what would happen if the violation occurred. Example instances show the cards it would light, the panel shows your settings today, and Simulate violation sends real, clearly marked test messages through your channels.
4. Prove: what Qpoint keeps as evidence (findings, enforcement events, config history), which is what framework detail and the export use.

The panel anatomy is the ASI04 stop Mark liked. The beat is the panel's sub-step (Watch · Tune · Drill · Prove).

The route: five stops, plus an opening and a close

Host guardrails (ASI05: root, sandbox, restricted paths) are a strong fit too. I left them as an optional sixth stop, "Where do my agents run code, and with what rights?", because the lab has no endpoint-process view to show yet.

Stop 1 · Source health

The concern. Contamination comes in through what the agent loads or reads: an MCP server or skill that's malicious, an impostor, or changed since someone checked it, a model from a provider nobody approved, a knowledge source seeded with instructions. The paper's live supply chain (ASI04), poisoned knowledge sources (ASI06 ex.1, ASI04 ex.6) and untrusted inputs (ASI01 #6).

Watch: a health card per source, as checks, not a score. A source is anything an agent loads or pulls from: MCP servers, skills, models and providers, harnesses (and their extensions), and knowledge or memory endpoints. Each source carries a row of checks, each passing, failing or not yet known:

Above the list, the counts read like the rest of the product: 41 sources · 35 healthy · 4 failing at least one check · 2 not yet known. "Healthy" means every check that applies passes, and an unknown never counts as passing, which is why the not-yet-known count is its own tile. The ring lands on the failing rows. (The artboard settled these numbers; the first draft of this line, "37 healthy", counted unknowns as healthy.)

Tune.

• Sanction a source for a team (an advanced exception that allows the resource, e.g. browser-tools for Engineering), with a reason and an until date.
• Require reviewed versions: P-PROVENANCE on, and a source that changes since review fails its check.
• Choose strictness per team: Finance on Enforce (an unsanctioned server is blocked), Engineering on Observe (it's flagged).
• Severity: raise "changed since review" to high for production device groups.
• Every change lands in the Policy Config draft with Change impact before publish ("would have blocked 2 servers on 5 endpoints last week").

Prove. First-seen and change events per source; findings for each failed check; Policy Config history showing who sanctioned what, when, and until when. Framework detail cites these under ASI04 #1, #2, #6 and #7.

Honest limit. Qpoint sees the parts in use and how they behave on the wire. It doesn't sign artifacts or scan their code (ASI04 #1 provenance attestation, #4 version control): those are the builder's.

Stop 2 · MCP: watch it, and tune it to suit you

The concern. MCP servers hand agents tools. A legitimate server can be used to do damage (ASI02), an impostor can sit in its place (ASI04), and a remote one can be reached over a weak channel (ASI07).

Watch: one server, end to end. The MCP server detail shows:

• Tools it offers, each tagged by what it does: reads, writes, sends, deletes, executes.
• Calls this week by tool and by consequence, with who made them (people, teams, agents).
• Transport: stdio or remote, encrypted or not.
• Reach: how many endpoints and people use it.
• Its health checks from stop 1.

The ring lands on the consequential tools (send, delete, execute), which is where ASI02's damage happens.

Tune: the controls, in the order a customer reaches for them.

Every change is staged in the Policy Config draft, Change impact replays last week against it ("14 calls would have paused for approval; 3 people affected; 0 blocked"), and nothing applies until publish. That's the paper's ASI08 #9 (replay before you expand policy) as an ordinary workflow.

Prove. Per-call records with the policy decision; approvals with who approved and how fast; the server's config history.

Honest limit. Qpoint governs the call on the wire. It can't see why the agent chose the tool (ASI01 intent) or whether a tool's own permissions are too wide inside the SaaS behind it (ASI02 #1 at the API).

Stops 3–5 in brief

• 3 · What can my agents change, and who signs off? Watch: consequential tool calls across all servers and harnesses, and approval health (approval rate, time-to-approve, bulk approvals). Tune: which verbs need approval, per team; spend ceilings. Prove: approvals and blocks. Answers ASI02 #2/#5, ASI03 #4, ASI05 #6, ASI08 #5, ASI09 #1.
• 4 · Do secrets or sensitive data reach a model? Watch: Data Protection, with secrets and personal data caught in prompts and tool payloads, by destination. Tune: redact vs block per data class; boundaries per team; exceptions for a sanctioned provider. Prove: redaction and block events. Answers ASI03 ex.2 (memory-based privilege retention), ASI06 #2, ASI09 #3.
• 5 · Stop it everywhere, and see how far it reached. Watch: blast radius on any source (people, devices, agents, sessions that touched it). Tune: block a source fleet-wide in one change, with Change impact; quarantine by context. Prove: timestamped enforcement events and the rollout's reach. Answers ASI04 #8 (kill switch), ASI10 #4/#5, ASI08 #4/#6/#9.

What's new (product asks)

Surfaces and knobs this tour assumes that neither the lab nor qdash has today:

1. Source health as a view across MCP servers, skills, providers, harnesses and knowledge endpoints, with per-source checks.
2. Tool-surface (descriptor) drift per MCP server.
3. Look-alike name check.
4. Known-incident check against a curated list (seeded from the paper's Appendix D).
5. Per-server tool allow-list on P-TOOL-ALLOW, and a verb set on P-TOOL-APPROVAL.
6. Tool tags by consequence (reads / writes / sends / deletes / executes).
7. Blast radius panel.

The artboards found three more, by checking the Tune beats against governance-fixture.ts:

8. Sanction a skill or knowledge endpoint. Resource.kind has mcpServer | account | provider | path | dataClass, so an advanced exception can allow a server or a provider but not a skill or a vector store.
9. Severity per scope. SeverityOverride is { policyId, severity, actor, at } with no scope, so "high on Production Macs" can't be said today.
10. Blocking an unreviewed version. P-PROVENANCE is enforceable: false. "Require reviewed versions" is Observe: a changed source fails its check and raises a finding, and nothing stops it loading.

What the artboards decided (2026-10-27)

Five boards on the concept canvas, in a new row under the v1 boards (y 2380, titled "v2 · The addressable tour"): Route, SourceHealth (stop 1 Watch), SourceTune (stop 1 Tune), McpWatch (stop 2 Watch), McpTune (stop 2 Tune). The v1 boards and Mark's Artboard-oy7o are untouched. The Prove beats are specified above but not drawn yet.

The panel, v2. It keeps the anatomy of the ASI04 stop Mark liked: 420 px docked right, the ring and one numbered callout on the live page, a "Here's yours" block, the mitigation chips, a "Yours" line, and Next. What changed:

• The title is the customer's question. The stop's short name sits above it ("Source health", "MCP · watch it, then tune it"), with the fit chip beside it.
• Under the title, three beat pills (Watch · Tune · Prove; done ones tinted, the current one filled), with the stop's risk IDs on the right (ASI04 · ASI06 · ASI01).
• The step bar has 7 segments (opening, five stops, close) and reads "Stop N of 5". Beats don't add segments.
• Mitigation rows carry the risk ID with the number (ASI04 #2), because a stop answers several risks.
• Chip states gain Staged (dashed outline) for a change that is in the draft but not published. The others are unchanged: Observed, Enforced, Evidenced, Ready, Off.
• The Watch action stays "Stage … at Observe". The Tune panel says that the tour staged the draft and you publish. The page's Publish button belongs to the customer; the tour never presses it.

Stop 1 Watch: Sources.

• A new Sources item heads Inventory in the nav, tagged new. Kind filters: All 41 · MCP servers 14 · Skills 9 · Providers 4 · Harnesses 6 · Knowledge 8.
• Four count tiles, with no total score: 41 sources, 35 healthy, 4 failing at least one check, 2 not yet known.
• Four marks, not three. Pass, fail, not yet known, and doesn't apply (a dash). A skill has no transport, tool surface or responses, and a provider has no reviewed version. A source with a check that doesn't apply can still be healthy; a source with one that is unknown can't.
• Each check's column header carries its fail count (Sanctioned 3 fail, Reviewed version 3, and 1 each for the rest). That's the "which check is hurting" view without a score.
• The list is sorted failing first, and the ring sits on the four failing rows:
  • postmark-mcp-server: unsanctioned, never reviewed, a look-alike origin, named in a public incident.
  • browser-tools: unsanctioned, never reviewed, has tripped injection inspection.
  • sheets-bridge: unsanctioned, HTTP without TLS.
  • jira-sync: sanctioned, but it changed since review and its tool surface grew (delete_issue).
• The two not-yet-known rows are release-notes (a skill with no recorded pin) and kb-vectors (a knowledge endpoint whose responses aren't inspected yet).
• The ASI04 #2 chip reads Observed on this beat, not "Enforced · Finance": Finance moves to Enforce in the Tune draft.

Stop 1 Tune: the Policy Config draft. Four staged changes, each tagged with the model term it uses:

1. P-MCP: allow browser-tools for Engineering until Dec 31, with a reason (advanced exception). Engineering otherwise stays on Observe.
2. P-MCP: Finance moves from Observe to Enforce (mode exception).
3. P-PROVENANCE: Off → Observe, org-wide (PolicyModeState), noting that blocking an unreviewed version is new.
4. P-PROVENANCE: severity medium → high on Production Macs (severity override, with per-scope tagged new).

Change impact is four tiles: 2 servers would have been blocked on 5 Finance endpoints (postmark-mcp-server, sheets-bridge); 31 browser-tools calls by 6 Engineering people are no longer flagged; 1 source fails Reviewed version; 0 calls blocked outside Finance. The ring is on Change impact, and the callout names ASI08 #9.

Stop 2 Watch: github server detail.

• The server is sanctioned for 5 teams. Its cards show transport (stdio, reaching api.github.com over TLS 1.3), reach (61 endpoints, 48 people, 1 unattended agent), the version (0.9.1, reviewed Oct 2), and its health checks (7 of 7 pass, linking back to Sources).
• Consequence tags: reads in neutral grey, writes in amber, and sends, deletes and executes filled red. Only those last three count as consequential and get ringed. Writes are common, and ringing them would ring most of the page.
• Calls this week by consequence: reads 8,379, writes 413, sends 96, deletes 14, executes 23. The 31 read tools collapse into one row.
• The ringed rows are add_issue_comment, delete_branch, delete_file, delete_repo (0 calls) and run_workflow.
• "By who" for those 133 calls: Engineering 92 (28 people), Platform 30 (4 people), release-agent 11 (unattended).

Stop 2 Tune: the server's Policy tab. The controls run in the v2 table's order. Each row shows the model term, and the two the model lacks are tagged new:

• Mode: P-TOOL-APPROVAL, Observe → Enforce. Mode is policy-wide, so the row says "approval, everywhere". A per-server mode would be one more ask; it's left unmarked for now.
• Per-team context: Engineering and Contractors on Enforce; Platform on Observe until Nov 30.
• Allow this server for: Contractors, until Dec 31.
• Tools allowed on this server (new): 38 of 39, with delete_repo struck out.
• Which actions need approval (new): a checkbox per verb, with only deletes ticked.
• Pin: 0.9.1. Another version is flagged, not blocked.
• Severity: a delete that ran without approval goes from medium to high.

The draft holds 7 changes. Change impact: 14 calls would have paused for approval; 3 people affected; 0 blocked. The 14 are delete_branch 9 (Priya, Jordan) and delete_file 5 (Mateo). Nothing is blocked because delete_repo was never called. Contractors have no calls yet. The ring is on the two new controls. The panel's "Ask your fleet" for this beat: What would change if deletes on github needed a person?

The Drill beat, and the lab tour (2026-10-27)

Mark, after the boards: talk about the signals Qpoint would emit for an addressable violation, and take people to the part of the dashboard that lights up (the DataMachines on Home, built from the top of each listing). Show error-state examples in the tour space. Let people simulate a violation so their chosen alert channels (Slack, PagerDuty, an HTTP POST) light up in a test run. Keep the dashboard's footprint to IDs. He then ruled: the panel floats; real messages; keep drill receipts; start row keys light; and rebuild the boards as lab mockups, keeping the canvas boards as concept sketches.

The tour layer (protocol, materials, drill rules, work packages): c125 tour-layer.md. In short: pages carry data-qp-id, and nothing else; the tour floats over them in its own dark-grape material; an Example is a real component with example props, floated over its live counterpart in a dashed frame; a Drill is a real delivery about a simulated cause, tagged in the delivery log and never in findings or evidence.

In the lab (rebuilt from the canvas boards, on the shared world): start at /pages/phase4/tour-owasp-agentic.

Signals, stops 1 and 2 (W5 in the c125 note). Severity is the catalog's recommended one unless Tuned.

What the lab decided beyond the boards:

• Examples replace the ring. When an Example covers a target, the step doesn't ring it; the dashed frame and its tab ("Example · your live value is N") do that job.
• "So, today" is computed, from each signal policy's live mode and from the channels that take each severity. So the sentence changes when Tune changes the draft or someone connects PagerDuty.
• The tour stages, and saves to the draft. It never publishes: the PublishTray still owns publishing. The stage action reports how many changes it staged.
• The new MCP controls are page state. The tool list per server and the approval verb set live on the page until the model has them. P-TOOL-APPROVAL's mode is real and staged.
• A drill raises what live would raise. A signal whose policy is Off is struck through ("Off: not raised") and isn't delivered. The Example's extra findings come from the same raised signals. "Your settings today" means live: a change staged in the draft shows there only once it's published, and the panel says so.
• Home leads with what needs attention. Open findings, Sensitive data and Machines come first, then Sources, MCP servers and Agent sessions. Both Drill beats' Examples sit in the two left columns, clear of the floating panel.
• The close rings OWASP Agentic's row on Compliance & Frameworks. That row still shows the listing's "Compliance 10%", which this cycle's Stage 2 cleanup (X1, X2) removes; until then the tour points at a percentage it shouldn't.
• The paper link goes to OWASP's resource page. Hosting the PDF with #page= anchors remains framework detail's decision (v1 §3).

Open

1. Is "source" the right noun for the customer? Alternatives: "supply", "parts", "components". The paper says components; "source health" is Mark's phrase.
2. Does knowledge/memory (RAG, vector stores) belong in Source health now, given Qpoint only sees the endpoint and what's sent to it?
3. Stop 6 (host guardrails): in, once the lab has an endpoint view, or left in the close?
4. Should writes be consequential? The artboards ring only sends, deletes and executes. A "writes need approval" default would pause 413 github calls a week.
5. The Prove beat for stops 1 and 2: one shared evidence view (findings + config history, filtered to the stop), or a board per stop?
6. Do drill receipts belong only in the delivery log, or also on framework detail as "alert path last tested" (for ASI08 and incident-response requirements)? They are kept apart from findings and evidence today.