@gpzhang2001/sharpkit-skills 0.2.1

package/skills/tooling/python.md

@@ -0,0 +1,109 @@
+---
+name: python
+description: Run Python through exec_command in the SDK sandbox. Use the image-baked caido_api module for Caido proxy automation from Python scripts.
+---
+
+# Python In The Sandbox
+
+Use `exec_command` for Python. There is no separate Python executor.
+
+Prefer writing reusable scripts to a `.py` file and running them with
+`python3 <name>.py`. For short one-off transformations, `python3 -c` or a
+small here-document is fine.
+
+The `shell` parameter on `exec_command` is for swapping POSIX shells
+(`bash`/`zsh`/`sh`), not for picking interpreters. Put the interpreter
+invocation in `cmd` instead: `cmd="python3 -c '...'"`, not
+`shell=python3, cmd="..."`. The `shell=<interpreter>` shortcut breaks
+in subtle ways — `python3` works only with `login=False` (because the
+SDK adds `-l`/`-i`), and other interpreters (`node`, `ruby`, `perl`)
+take `-e` not `-c` so they fail even with `login=False`.
+
+## Proxy Automation From Python
+
+The sandbox image includes an installed `caido_api` module. Import it
+explicitly when Python code needs Caido traffic or replay access:
+
+```python
+from caido_api import (
+    list_requests,
+    list_sitemap,
+    repeat_request,
+    scope_rules,
+    view_request,
+    view_sitemap_entry,
+)
+```
+
+All helpers are async. Use them inside `asyncio.run(...)` or an async
+function:
+
+```python
+import asyncio
+
+from caido_api import list_requests, view_request
+
+
+async def main():
+    posts = await list_requests(
+        httpql_filter='req.method.eq:"POST" AND req.path.cont:"/api/"',
+        first=50,
+    )
+    candidates = []
+    for edge in posts.edges:
+        request_id = edge.node.request.id
+        body = await view_request(request_id, part="request")
+        raw = body.request.raw.decode("utf-8", errors="replace")
+        if "id=" in raw or "user=" in raw:
+            candidates.append(request_id)
+
+    print(f"{len(candidates)} candidates")
+    print(candidates[:10])
+
+
+asyncio.run(main())
+```
+
+Available helpers:
+
+- `list_requests(httpql_filter=, first=50, after=, sort_by=, sort_order=, scope_id=)` returns a cursor-paginated Caido SDK `Connection`.
+- `view_request(request_id, part="request")` returns a Caido SDK request object with raw request/response bytes.
+- `repeat_request(request_id, modifications={...})` replays a captured request after modifying `url`, `params`, `headers`, `body`, or `cookies`.
+- `list_sitemap(scope_id=, parent_id=, depth="DIRECT", page=1)` walks Caido's request-tree view of the discovered surface. Omit `parent_id` for root domains; pass an entry id with `depth="DIRECT"` or `"ALL"` to drill in.
+- `view_sitemap_entry(entry_id)` returns one entry plus its 30 most recent related requests.
+- `scope_rules(action, allowlist=, denylist=, scope_id=, scope_name=)` manages Caido scopes.
+
+For one-off arbitrary requests (e.g. probing a fresh endpoint, hitting an
+external API), use `exec_command` with `curl` / `httpx` / `requests`. The
+sandbox's `HTTP_PROXY` env routes all such traffic through Caido
+automatically, so it shows up in `list_requests` and you can use
+`repeat_request` to replay-and-modify any of it.
+
+## Workflow
+
+For iterative exploit work, put code in a file:
+
+```text
+1. Create or edit a task-unique script (e.g. `poc_<task-id>.py`, so it can't
+   clobber a project file or another agent's script) with `apply_patch`.
+2. Run it with `exec_command`: `python3 poc_<task-id>.py`.
+3. Edit and rerun until the proof-of-concept is reliable.
+```
+
+## Installing extra packages
+
+The sandbox's Python lives in `/app/.venv`, and it is the active virtualenv
+(`python3` / `pip` already resolve to it). The following common libraries are
+**pre-installed** — import them directly, no install step needed:
+`requests`, `httpx`, `beautifulsoup4` (`bs4`), `lxml`, `pyjwt` (`jwt`),
+`cryptography`.
+
+To add a one-off dependency for an exploit script, use `uv` (already in the
+image and much faster than pip):
+
+```bash
+uv pip install --python /app/.venv/bin/python <package>
+```
+
+Plain `pip install <package>` also works because the venv is active. Install
+before you import, so scripts don't fail with `ModuleNotFoundError`.

package/skills/tooling/semgrep.md

@@ -0,0 +1,72 @@
+---
+name: semgrep
+description: Exact Semgrep CLI structure, metrics-off scanning, scoped ruleset selection, and automation-safe output patterns.
+---
+
+# Semgrep CLI Playbook
+
+Official docs:
+- https://semgrep.dev/docs/cli-reference
+- https://semgrep.dev/docs/getting-started/cli
+- https://semgrep.dev/docs/semgrep-code/semgrep-pro-engine-intro
+
+Canonical syntax:
+`semgrep scan [flags]`
+
+High-signal flags:
+- `--config <rule_or_ruleset>` ruleset, registry pack, local rule file, or directory
+- `--metrics=off` disable telemetry and metrics reporting
+- `--json` JSON output
+- `--sarif` SARIF output
+- `--output <file>` write findings to file
+- `--severity <level>` filter by severity
+- `--error` return non-zero exit when findings exist
+- `--quiet` suppress progress noise
+- `--jobs <n>` parallel workers
+- `--timeout <seconds>` per-file timeout
+- `--exclude <pattern>` exclude path pattern
+- `--include <pattern>` include path pattern
+- `--exclude-rule <rule_id>` suppress specific rule
+- `--baseline-commit <sha>` only report findings introduced after baseline
+- `--pro` enable Pro engine if available
+- `--oss-only` force OSS engine only
+
+Agent-safe baseline for automation:
+`semgrep scan --config p/default --metrics=off --json --output semgrep.json --quiet --jobs 4 --timeout 20 /workspace`
+
+Common patterns:
+- Default security scan:
+  `semgrep scan --config p/default --metrics=off --json --output semgrep.json --quiet /workspace`
+- High-severity focused pass:
+  `semgrep scan --config p/default --severity ERROR --metrics=off --json --output semgrep_high.json --quiet /workspace`
+- OWASP-oriented scan:
+  `semgrep scan --config p/owasp-top-ten --metrics=off --sarif --output semgrep.sarif --quiet /workspace`
+- Language- or framework-specific rules:
+  `semgrep scan --config p/python --config p/secrets --metrics=off --json --output semgrep_python.json --quiet /workspace`
+- Scoped directory scan:
+  `semgrep scan --config p/default --metrics=off --json --output semgrep_api.json --quiet /workspace/services/api`
+- Pro engine check or run:
+  `semgrep scan --config p/default --pro --metrics=off --json --output semgrep_pro.json --quiet /workspace`
+
+Critical correctness rules:
+- Always include `--metrics=off`; Semgrep sends telemetry by default.
+- Always provide an explicit `--config`; do not rely on vague or implied defaults.
+- Prefer `--json --output <file>` or `--sarif --output <file>` for machine-readable downstream processing.
+- Keep the target path explicit; use an absolute or clearly scoped workspace path instead of `.` when possible.
+- If Pro availability matters, check it explicitly with a bounded command before assuming cross-file analysis exists.
+
+Usage rules:
+- Start with `p/default` unless the task clearly calls for a narrower pack.
+- Add focused packs such as `p/secrets`, `p/python`, or `p/javascript` only when they match the target stack.
+- Use `--quiet` in automation to reduce noisy logs.
+- Use `--jobs` and `--timeout` explicitly for reproducible runtime behavior.
+- Do not use `-h`/`--help` for routine operation unless absolutely necessary.
+
+Failure recovery:
+- If scans are too slow, narrow the target path and reduce the active rulesets before changing engine settings.
+- If scans time out, increase `--timeout` modestly or lower `--jobs`.
+- If output is too broad, scope `--config`, add `--severity`, or exclude known irrelevant paths.
+- If Pro mode fails, rerun with `--oss-only` or without `--pro` and note the loss of cross-file coverage.
+
+If uncertain, query web_search with:
+`site:semgrep.dev semgrep <flag> cli`

package/skills/tooling/sqlmap.md

@@ -0,0 +1,67 @@
+---
+name: sqlmap
+description: sqlmap target syntax, non-interactive execution, and common validation/enumeration workflows.
+---
+
+# sqlmap CLI Playbook
+
+Official docs:
+- https://github.com/sqlmapproject/sqlmap/wiki/usage
+- https://sqlmap.org
+
+Canonical syntax:
+`sqlmap -u "<target_url_with_params>" [options]`
+
+High-signal flags:
+- `-u, --url <url>` target URL
+- `-r <request_file>` raw HTTP request input
+- `-p <param>` test specific parameter(s)
+- `--batch` non-interactive mode
+- `--level <1-5>` test depth
+- `--risk <1-3>` payload risk profile
+- `--threads <n>` concurrency
+- `--technique <letters>` technique selection
+- `--forms` parse and test forms from target page
+- `--cookie <cookie>` and `--headers <headers>` authenticated context
+- `--timeout <seconds>` and `--retries <n>` transport stability
+- `--tamper <scripts>` WAF/input-filter evasion
+- `--random-agent` randomize user-agent
+- `--ignore-proxy` bypass configured proxy
+- `--dbs`, `-D <db> --tables`, `-D <db> -T <table> --columns`, `-D <db> -T <table> -C <cols> --dump`
+- `--flush-session` clear cached scan state
+
+Agent-safe baseline for automation:
+`sqlmap -u "https://target.tld/item?id=1" -p id --batch --level 2 --risk 1 --threads 5 --timeout 10 --retries 1 --random-agent`
+
+Common patterns:
+- Baseline injection check:
+  `sqlmap -u "https://target.tld/item?id=1" -p id --batch --level 2 --risk 1 --threads 5`
+- POST parameter testing:
+  `sqlmap -u "https://target.tld/login" --data "user=admin&pass=test" -p pass --batch --level 2 --risk 1`
+- Form-driven testing:
+  `sqlmap -u "https://target.tld/login" --forms --batch --level 2 --risk 1 --random-agent`
+- Enumerate DBs:
+  `sqlmap -u "https://target.tld/item?id=1" -p id --batch --dbs`
+- Enumerate tables in DB:
+  `sqlmap -u "https://target.tld/item?id=1" -p id --batch -D appdb --tables`
+- Dump selected columns:
+  `sqlmap -u "https://target.tld/item?id=1" -p id --batch -D appdb -T users -C id,email,role --dump`
+
+Critical correctness rules:
+- Always include `--batch` in automation to avoid interactive prompts.
+- Keep target parameter explicit with `-p` when possible.
+- Use `--flush-session` when retesting after request/profile changes.
+- Start conservative (`--level 1-2`, `--risk 1`) and escalate only when needed.
+
+Usage rules:
+- Keep authenticated context (`--cookie`/`--headers`) aligned with manual validation state.
+- Prefer narrow extraction (`-D/-T/-C`) over broad dump-first behavior.
+- Do not use `-h`/`--help` during normal execution unless absolutely necessary.
+
+Failure recovery:
+- If results conflict with manual testing, rerun with `--flush-session`.
+- If blocked by filtering/WAF, reduce `--threads` and test targeted `--tamper` chains.
+- If initial detection misses likely injection, increment `--level`/`--risk` gradually.
+
+If uncertain, query web_search with:
+`site:github.com/sqlmapproject/sqlmap/wiki/usage sqlmap <flag>`

package/skills/tooling/subfinder.md

@@ -0,0 +1,66 @@
+---
+name: subfinder
+description: Subfinder passive subdomain enumeration syntax, source controls, and pipeline-ready output patterns.
+---
+
+# Subfinder CLI Playbook
+
+Official docs:
+- https://docs.projectdiscovery.io/opensource/subfinder/usage
+- https://docs.projectdiscovery.io/opensource/subfinder/running
+- https://github.com/projectdiscovery/subfinder
+
+Canonical syntax:
+`subfinder [flags]`
+
+High-signal flags:
+- `-d <domain>` single domain
+- `-dL <file>` domain list
+- `-all` include all sources
+- `-recursive` use recursive-capable sources
+- `-s <sources>` include specific sources
+- `-es <sources>` exclude specific sources
+- `-rl <n>` global rate limit
+- `-rls <source=n/s,...>` per-source rate limits
+- `-proxy <http://host:port>` proxy outbound source requests
+- `-silent` compact output
+- `-o <file>` output file
+- `-oJ, -json` JSONL output
+- `-cs, -collect-sources` include source metadata (`-oJ` output)
+- `-nW, -active` show only active subdomains
+- `-timeout <seconds>` request timeout
+- `-max-time <minutes>` overall enumeration cap
+
+Agent-safe baseline for automation:
+`subfinder -d example.com -all -recursive -rl 20 -timeout 30 -silent -oJ -o subfinder.jsonl`
+
+Common patterns:
+- Standard passive enum:
+  `subfinder -d example.com -silent -o subs.txt`
+- Broad-source passive enum:
+  `subfinder -d example.com -all -recursive -silent -o subs_all.txt`
+- Multi-domain run:
+  `subfinder -dL domains.txt -all -recursive -rl 20 -silent -o subfinder_out.txt`
+- Source-attributed JSONL output:
+  `subfinder -d example.com -all -oJ -cs -o subfinder_sources.jsonl`
+- Passive enum via explicit proxy:
+  `subfinder -d example.com -all -recursive -proxy http://127.0.0.1:48080 -silent -oJ -o subfinder_proxy.jsonl`
+
+Critical correctness rules:
+- `-cs` is useful only with JSON output (`-oJ`).
+- Many sources require API keys in provider config; low results can be config-related, not target-related.
+- `-nW` performs active resolution/filtering and can drop passive-only hits.
+- Keep passive enum first, then validate with `httpx`.
+
+Usage rules:
+- Keep output files explicit when chaining to `httpx`/`nuclei`.
+- Use `-rl/-rls` when providers throttle aggressively.
+- Do not use `-h`/`--help` for routine tasks unless absolutely necessary.
+
+Failure recovery:
+- If results are unexpectedly low, rerun with `-all` and verify provider config/API keys.
+- If provider errors appear, lower `-rl` and apply `-rls` per source.
+- If runs take too long, lower scope or split domain batches.
+
+If uncertain, query web_search with:
+`site:docs.projectdiscovery.io subfinder <flag> usage`

package/skills/vulnerabilities/agentic_system_security.md

@@ -0,0 +1,207 @@
+---
+name: agentic-system-security
+description: Security testing for authorized AI agents and MCP-style tool ecosystems, covering effective authority, tool/resource/prompt inventory, confused-deputy behavior, side-effect authorization, cross-tenant isolation, executable component supply chain, shadow integrations, and repeatable safety regression
+---
+
+# Agentic System Security
+
+Use this skill when an AI system can select tools, retrieve resources, invoke remote/local services, maintain memory, delegate to other agents, or install skills/plugins. Pair it with `llm_prompt_injection` for instruction attacks and classic vulnerability skills for the downstream HTTP, cloud, filesystem, identity, or code-execution sink.
+
+Prompt text is not an authorization boundary. Treat the agent runtime as a confused deputy whose effective authority is bounded by the union of its credentials, tools, resources, network reach, filesystem access, delegated agents, and approval policy, then reduce that upper bound to the actually reachable subset by tracing token audience, scopes, routing, target authorization, environment, and approval flow.
+
+## Effective-Authority Map
+
+Draw the complete path:
+
+```text
+user / external content
+  -> model context and memory
+  -> planner / router / policy
+  -> tool or delegated agent
+  -> credential and target system
+  -> side effect / returned data
+```
+
+Inventory, for each node:
+
+- trust source and tenant/user ownership
+- immutable component identity, package/server name, version, and transport
+- tools, resources, prompts, model endpoints, plugins, skills, and MCP servers
+- credential identity, issuer, audience/resource, subject, tenant, scopes/roles, expiry, downstream token exchange, environment, and where it is injected
+- readable data and write/execute capabilities
+- network/listener exposure and test-versus-production target
+- argument validation, authorization point, approval point, schema/argument digest, delegated principal propagation, and audit log
+- data returned to the model and whether it can contain new instructions
+
+Test from the lowest-privileged realistic user and device. The key comparison is the user's authority versus the agent/tool credential's authority.
+
+## Core Test Areas
+
+### Shadow Agent and AI Discovery
+
+Do not assume the approved application inventory contains every agent, model endpoint, browser extension, local MCP server, or AI API integration. Correlate multiple independent signals:
+
+- DNS/proxy/egress logs for first-seen model, agent, vector database, plugin, and AI SaaS domains
+- OAuth/SSO grants, enterprise-app consent, service principals, API tokens, and unusual delegated scopes
+- endpoint processes, browser extensions/native messaging, listening loopback ports, and MCP client/server configuration
+- repository, CI/CD, secrets-manager, and container/image references to model providers, tool servers, and AI credentials
+- cloud-hosted model endpoints, notebooks, functions, gateways, and procurement/expense/SaaS inventory
+
+Baseline local discovery from the host before interpreting network or SSO signals:
+
+```bash
+# macOS
+lsof -nP -iTCP -sTCP:LISTEN
+ps -axo pid,ppid,user,command
+
+# Linux
+ss -lntp
+ps -eo pid,ppid,user,args
+
+# Windows PowerShell
+Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
+Get-Process | Select-Object Id,ProcessName,Path
+
+# Cross-platform config and credential leads
+rg -l 'mcpServers|modelContextProtocol|OPENAI_API_KEY|ANTHROPIC_API_KEY|AZURE_OPENAI_ENDPOINT' <reviewed-roots>
+```
+
+Correlate each listener or config hit to PID/container, parent process, binary hash/version, launch command, config file, destination, and credential reference before calling it an active agent component. A loopback listener is a lead, not proof of reachable authority.
+
+Classify each discovered integration by data read, data write, external communication, execution, identity/admin, and production reach. Human-validate attribution before treating a domain or key name as active AI use. Inspect unauthenticated local MCP/agent listeners separately; network inventory tools often miss loopback-only services.
+
+### Tool Discovery and Argument Boundaries
+
+- Enumerate advertised and conditionally available tools, resources, prompts, schemas, annotations, and delegated agents.
+- Compare what the UI exposes with what the protocol/runtime accepts directly.
+- Test missing, extra, duplicate, nested, oversized, alternate-type, and cross-tenant identifiers in tool arguments.
+- Validate scheme/host/path, filesystem paths, cloud resource IDs, recipient identities, SQL/query fields, and command arguments at the tool boundary.
+- Treat tool descriptions, names, examples, resource metadata, and returned content as attacker-influenceable unless provenance is enforced.
+- Canonicalize tool identity as `server identity/version + endpoint/transport + tool name + schema digest`; do not collapse two identically named tools from different servers into one trust decision.
+- Treat protocol hints such as `readOnlyHint`, `destructiveHint`, `idempotentHint`, and `openWorldHint` as untrusted metadata, not authorization.
+- Verify that unknown tools or schema-invalid calls fail closed without falling back to a broader handler.
+
+### Confused Deputy and Consequential Actions
+
+- Ask whether untrusted user/document/tool text can choose the tool, target, identity, or action.
+- Test read-to-write escalation: a summarizer should not send, publish, delete, purchase, deploy, or modify because retrieved text requests it.
+- Test whether approval binds the exact server identity/version, tool name, schema digest, normalized arguments, credential, target, side effect, and expiry. Revalidate those fields immediately before execution; a generic “continue?” is weak if arguments can change after approval.
+- Exercise replay, retry, parallel calls, partial failure, cancellation, and delegated execution for duplicate or bypassed actions.
+- Prove impact at the actual target and audit log. Model narration or a fabricated tool result is not evidence.
+- Use dry-run/no-op/read-only operations first; require explicit human approval for consequential operations.
+
+### Identity, Tenant, and Environment Isolation
+
+- Vary user, workspace, tenant, session, conversation, and delegated-agent identity independently.
+- Test whether one tenant can reference another tenant's resources, tool sessions, caches, vector entries, files, or credentials.
+- Check whether development/test tools or credentials can reach production, and whether local tools inherit broad workstation authority.
+- Verify credential scoping at the target service, not only in the agent's application logic.
+- Confirm memory and cached tool results are partitioned and revoked when identity or role changes.
+
+### MCP and Local Tool Servers
+
+- Inventory stdio, streamable HTTP, SSE/legacy, and custom transports; record bind address, origin/auth controls, process command, environment, and lifecycle.
+- Look for unauthenticated loopback services reachable from browsers, containers, local users, SSRF, port forwarding, or shared hosts.
+- Compare `tools/list`, `resources/list`, and `prompts/list` results across identities, but do not assume listing means calling is authorized.
+- For each tool, validate the same authorization and argument checks through every supported transport.
+- Treat server-launched subprocess configuration, environment variables, and working directories as sensitive executable configuration.
+- For HTTP/SSE transports, validate OAuth issuer, signature, expiry, audience/resource, tenant, and scope claims at the server boundary. Reject tokens minted for the wrong audience, and do not treat a session ID as identity.
+- For downstream APIs, do not pass through the same bearer token unless the target explicitly authorizes that audience and principal. Separate upstream MCP authentication from downstream target authorization.
+- For browser or loopback OAuth, review redirect URI, state/PKCE handling, localhost binding, and consent proxying. Treat metadata fetches and tool discovery on remote servers as SSRF-relevant surfaces.
+- For stdio servers, the launch command and environment are already code execution. Discovery must not execute an unreviewed server binary or mutable package tag.
+
+### Executable Component Supply Chain
+
+Every skill, plugin, MCP server, model adapter, package, and update channel is an executable or behavior-shaping dependency. Record:
+
+- canonical source, publisher, package namespace, pinned version and integrity/provenance
+- install/update mechanism, manifest/lockfile/config source, mutable tags, automatic updates, and rollback path
+- declared and effective permissions, credentials, filesystem/network access
+- transitive dependencies and lifecycle scripts
+- review/approval ownership and last verification date
+
+In agent and MCP configs, inspect `command: npx` with `-y` and a bare package or
+binary name. The process can fetch code without an interactive prompt and then
+run it with the agent's authority. Load `npx_confusion` to determine whether the
+name resolves locally, becomes a public package spec, and belongs to the
+intended publisher.
+
+Test missing/private-name fallback, typosquatting exposure, mutable remote instructions, compromised-update blast radius, and whether an “instruction-only” component can invoke tools or modify executable files. Resolve `latest`, floating git refs, and mutable image tags to immutable versions or digests before launch. Do not claim or publish contestable package names as proof, and do not execute unknown packages just to discover what they are.
+
+Load `infrastructure_lifecycle` when a skill, plugin, MCP server, model adapter, tool-schema origin, package namespace, or update endpoint is retired, mutable, or externally reassignable. Passive receipt of an agent heartbeat or catalog request does not authorize returning tool definitions, prompts, commands, or executable content.
+
+### Output, Telemetry, and Failure Modes
+
+- Validate model/tool output before it reaches HTML, shell, SQL, URLs, file paths, templates, or a second agent.
+- Ensure logs record initiating user, tool/server identity, sanitized arguments, approval, target, result, and correlation ID without storing secrets.
+- Test timeout, tool error, truncated output, malformed result, model retry, and policy-service failure. Failures should not silently switch to a more privileged tool or credential.
+- Verify kill switches, credential revocation, and disabling a component actually terminate active sessions and queued work.
+
+## Safe Testing Workflow
+
+1. **Map** every capability and trust boundary before injecting prompts.
+2. **Classify** tools as read, write, execute, communicate, identity/admin, or external-cost.
+3. **Establish controls** with dedicated test tenants, synthetic data, read-only credentials, budgets, and target allowlists.
+4. **Probe one boundary** at a time: selection, arguments, authorization, approval, execution, result handling.
+5. **Validate the side effect** in the target system and audit trail; compare denied and allowed identities.
+6. **Chain confirmed primitives** using the effective-authority and capability map from this skill.
+7. **Clean up and revoke** created data, sessions, tokens, and local servers.
+8. **Turn each confirmed case into a regression** across relevant models, prompts, tools, roles, and environments.
+
+## MCP Inspector (Conditional)
+
+Use the official [MCP Inspector](https://github.com/modelcontextprotocol/inspector) only against a reviewed local/test server:
+
+```bash
+npx @modelcontextprotocol/inspector@<reviewed-version> --cli \
+  --config reviewed-mcp.json --server test-server \
+  --method tools/list --format json
+```
+
+- Current upstream requirements should be checked before pinning; as of August 12, 2026, MCP Inspector 2.1.0 requires Node.js `>=22.19.0`.
+- Prefer CLI/TUI and loopback binding over exposing the web UI.
+- Preserve the generated API token; never disable authentication or bind the process-spawning backend to an external interface.
+- Do not publish ports 6274/6277 or pass through the Docker socket/host devices.
+- `tools/list` is protocol-read-only, but launching/initializing an arbitrary stdio server executes it and list handlers can still have process-side effects. Review the server command/config first. Calling a tool can perform real external actions.
+- Treat the inspected server command/config as executable; `npx` also downloads code, so pin a reviewed package version for repeatable or sensitive work.
+
+## Regression With Promptfoo (Conditional)
+
+[Promptfoo](https://github.com/promptfoo/promptfoo) can encode a bounded model/tool safety matrix after manual validation:
+
+```bash
+npx promptfoo@<reviewed-version> eval
+```
+
+- Current upstream engine constraints should be checked before pinning; as of August 12, 2026, Promptfoo documents Node.js `^20.20.0` or `>=22.22.0`.
+- Use synthetic prompts/data and a dedicated test provider/project.
+- Provider calls transmit data externally and can incur cost even when evaluation orchestration is local. Set request/concurrency and spending ceilings.
+- Pin model, provider, prompt, tool schema, retrieval corpus revision, and evaluator versions.
+- Include allowed and denied controls across roles/tenants; use multiple runs for nondeterministic outcomes.
+- Automated red-team labels are leads, not findings. Confirm the real tool call, data access, or side effect manually.
+- Store redacted results; evaluation logs can contain system prompts, secrets, retrieved data, and tool arguments.
+
+## Validation
+
+A report must include:
+
+1. initiating identity, tenant, model/runtime, and exact component versions
+2. effective-authority map and relevant tool/resource schema
+3. untrusted input source and decision boundary crossed
+4. exact target-side operation or data access, with redacted audit evidence
+5. denied identity/input and allowed control results across repeat runs
+6. credential, feature, approval, environment, and user-interaction prerequisites
+7. cleanup/revocation and a bounded regression case
+
+## False Positives
+
+- The model claims a tool ran but the target and audit log show no action.
+- A listed tool cannot be invoked by the tested identity or validates arguments safely.
+- A safety refusal changes wording but effective capability remains denied.
+- Cross-session output is synthetic, cached public data, or hallucinated rather than another user's data.
+- A scanner flags an instruction string without showing that it reaches a privileged decision or sink.
+- A component has broad declared permissions but the runtime credential/network policy prevents the claimed access.
+
+## Summary
+
+Agent security is capability security. Map the real authority carried through models, tools, credentials, plugins, and delegated agents; validate authorization and approval at the target-side effect; treat every installed component as executable supply chain; and preserve each confirmed boundary failure as a bounded regression.