Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/pharosone/vector-plugin/harden-from-findingnpx skills add pharosone/vector-plugin --skill harden-from-findinggit clone --depth 1 https://github.com/pharosone/vector-pluginWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00066 | $0.00683 |
| Opus 5 | $0.00033 | $0.00342 |
| Sonnet 5 | $0.00013 | $0.00137 |
| Haiku 4.5 | $0.00007 | $0.00068 |
Grade A, and why
harden-from-finding scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Goal
Harden the user's agent against a specific red-team finding from Vector.
Context — gather the finding details
You need five fields about the failed finding: session_id, attack_id, category / subcategory, the attacker prompt, the agent's broken response, and the judge's reasoning. There are two ways to get them:
-
MCP-first (preferred). If the Vector MCP server is connected in this client (this plugin pre-wires it), use the MCP tools:
get_session({ session_id })→ confirms the session exists and iscompleted.list_attacks({ session_id })→ finds the attack matchingattack_id.- The session report (
wait_for_reportorget_report) holds the verdict, judge reasoning, and the agent's recorded response for each finding. Ask the user only forsession_idandattack_idand pull the rest yourself.
-
Manual paste (fallback). Ask the user to open the finding in the cabinet (
/sessions/{session_id}page → click the failed attack row) and paste:session_idattack_idcategory/subcategory- Attacker prompt (verbatim, the full text)
- Agent's response (verbatim, including any leak)
- Judge reasoning (
reasonfield on the finding)
Tasks
- Read the current system prompt and tool definitions of the agent in this repo.
- Identify the specific weakness that allowed this attack to succeed. Quote the exact phrasing in the system prompt or the exact tool description that the attacker exploited.
- Propose concrete, minimal edits — quote the exact lines that should change and write the replacement inline. No "consider tightening this section" — show the diff.
- Add a unit / integration test (in whichever test runner the repo already uses — pytest / vitest / jest / etc.) that:
- Replays this exact attacker prompt against the agent.
- Asserts the safe behaviour (e.g., a refusal phrase, or that no PII appears in the response, or that a specific tool wasn't called).
- Names the test after the
attack_idso it's traceable back to Vector.
- Do NOT over-correct. Avoid blanket refusals that would harm normal traffic — the fix should be the narrowest change that closes this specific gap. If the proposed fix could break a normal use case, flag it and ask before applying.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 49 lines · 66 tokens per session scan A bf78e91fa168
harden-from-finding is a skill published in the GitHub repository pharosone/vector-plugin (1 stars, last pushed 3mo ago), licensed MIT. It adds 66 tokens to every session and 683 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
resemble-detect
Deepfake detection and media safety — detect AI-generated audio, images, and video, trace synthesis sources, and analyze media intelligence using direct Resemble AI API calls.
AI System Quality Engineer
Test LLM, RAG, MCP, and agentic systems end to end. Build golden datasets, run deterministic checks and LLM judges, score retrieval, probe prompt injection, verify tool use, and gate CI on thresholds. Orchestrates DeepEval, Ragas, promptfoo, and Langfuse.
Agent Evaluation Framework Builder
Designs an eval suite for an LLM agent or pipeline including success metrics, trajectory scoring, LLM-as-judge setup, and regression test cases.
agent-resilience-testing
Orchestrates end-to-end resilience testing for LLM agents with AgentBreak, including LLM infrastructure failures, prompt injection, agent skill supply-chain risk, guardrail verification, and MCP server/tool failures. Use when the user asks to "test my agent for resilience", "chaos test this agent", "find failure modes…
bug_fix
Constrains the Agent to follow a structured bug fix process — locate → root cause → fix → regression verify.
feature_dev
Constrains the Agent to follow a structured feature development process — requirements → design → implement → verify.