feat(mcp): add ATR-derived MCP detection rules for further attack surfaces

data/mcp/mcp_missing_authentication.yaml

@@ -0,0 +1,53 @@
+info:
+  id: "mcp_missing_authentication"
+  name: "MCP Server Missing / Weak Authentication Detection"
+  description: "Detect MCP servers that expose tools over a network transport (HTTP/SSE/streamable) with no authentication, weak static tokens, or bind to non-loopback interfaces, letting any reachable client invoke sensitive tools."
+  author: "ATR (Agent Threat Rules)"
+  categories:
+    - code
+
+prompt_template: |
+  As a professional AI-agent security analyst, precisely detect missing or weak authentication on MCP servers exposed over a network transport. If a networked MCP server invokes sensitive tools without verifying the caller, any reachable party controls the agent's tools. Require concrete evidence of a network-exposed transport lacking real auth; only report with evidence.
+
+  ## Vulnerability Definition
+  This vulnerability occurs when an MCP server serving the HTTP / SSE / streamable
+  transport accepts and executes tool calls without authenticating the client — no
+  token check, a hardcoded/empty token, auth that is parsed but never enforced, or a
+  bind to `0.0.0.0` / a public interface that widens exposure beyond localhost.
+
+  ## Detection Criteria (require a network transport without enforced auth)
+
+  ### 1. Network transport without an auth gate
+  **Code Patterns:**
+  - HTTP/SSE/streamable MCP server route handlers that reach tool dispatch with no
+    credential verification middleware.
+  - Auth header read but not validated, or validation whose failure path still
+    proceeds.
+
+  ### 2. Weak or static credentials
+  **Code Patterns:**
+  - Hardcoded token / API key, empty-string default token, or a comparison that
+    accepts any value.
+
+  ### 3. Over-broad network binding
+  **Code Patterns:**
+  - Server bound to `0.0.0.0` or a public interface without a compensating auth
+    layer, exposing a previously loopback-only server.
+
+  ## Strict Judgment Standards
+  - **Enforced auth**: Do not report servers that verify a token / OAuth / mTLS and
+    reject unauthenticated calls before dispatch.
+  - **Stdio transport**: Do not report stdio-only servers with no network surface.
+  - **Loopback + documented**: Do not report localhost binds that are clearly the
+    intended, non-exposed deployment.
+
+  ## Output Requirements
+  Only output when finding concrete missing/weak-auth evidence:
+  - Specific file paths and line numbers
+  - The exposed transport/route and the absent or ineffective auth check
+  - Technical analysis: how an unauthenticated caller reaches tool execution
+  - Impact assessment: unauthorized tool invocation, data access, lateral movement
+  - Remediation: require and enforce a real credential (OAuth / token / mTLS) before
+    dispatch, bind to loopback by default, fail closed on auth errors.
+
+  **Strict Requirement: show the concrete unauthenticated path to tool execution. Remain silent when no concrete evidence exists.**

data/mcp/mcp_path_traversal.yaml

@@ -0,0 +1,55 @@
+info:
+  id: "mcp_path_traversal"
+  name: "MCP Tool Path Traversal / Arbitrary File Access Detection"
+  description: "Detect MCP file tools that join tool-call path arguments into filesystem operations without confinement, allowing '..' traversal or absolute paths to read or write files outside the intended root."
+  author: "ATR (Agent Threat Rules)"
+  categories:
+    - code
+
+prompt_template: |
+  As a professional AI-agent security analyst, precisely detect path-traversal / arbitrary-file-access vulnerabilities in MCP server tools. The agent controls path arguments; if they reach a filesystem call without confinement to a root, the server reads or writes arbitrary files. Require a concrete tainted-path-to-filesystem-sink path; only report with evidence.
+
+  ## Vulnerability Definition
+  Path traversal occurs when an MCP tool builds a filesystem path from a tool
+  argument (filename, path, directory) and opens, reads, writes, deletes, or lists
+  it without ensuring the resolved real path stays inside an allowed base directory.
+  `../` sequences, absolute paths, symlinks, or `~` expansion escape the intended
+  root.
+
+  ## Detection Criteria (require a tainted path reaching a filesystem sink)
+
+  ### 1. Unconfined path join
+  **Code Patterns:**
+  - Tool argument concatenated or `os.path.join` / `filepath.Join`-ed into a path
+    passed to `open`, `read_file`, `write_file`, `os.remove`, `readdir`, or a static
+    file server, with no post-resolution containment check.
+
+  ### 2. Missing canonicalization + base-dir check
+  **Code Patterns:**
+  - No `realpath` / `filepath.Abs` + `strings.HasPrefix(base)` (or equivalent) to
+    confirm the resolved path is under the allowed root.
+  - Blocklist-only defenses (stripping `..`) that miss encoded, absolute, or symlink
+    bypasses.
+
+  ### 3. Sensitive-target reachability
+  **Code Patterns:**
+  - Traversal that can reach `/etc/passwd`, `~/.ssh`, `.env`, cloud credential files,
+    or write into startup/config locations.
+
+  ## Strict Judgment Standards
+  - **Confined roots**: Do not report tools that canonicalize the path and verify it
+    is inside a fixed base directory before use.
+  - **Fixed paths**: Do not report filesystem access to constant, non-argument paths.
+  - **Read-only public assets**: Do not report serving a bounded static directory
+    with proper containment.
+
+  ## Output Requirements
+  Only output when finding concrete traversal evidence:
+  - Specific file paths and line numbers
+  - The tainted path argument and the filesystem sink it reaches
+  - Technical analysis: how `..` / absolute / symlink input escapes the root
+  - Impact assessment: which sensitive files can be read or written
+  - Remediation: canonicalize then assert the real path is under an allow-listed
+    base, reject absolute paths and `..`, drop symlink following.
+
+  **Strict Requirement: show the concrete path-to-filesystem-sink path. Remain silent when no concrete evidence exists.**

data/mcp/mcp_resource_prompt_injection.yaml

@@ -0,0 +1,54 @@
+info:
+  id: "mcp_resource_prompt_injection"
+  name: "MCP Resource / Prompt Indirect Injection Detection"
+  description: "Detect MCP servers that build resource contents or prompt templates from untrusted external data and return them to the host agent as trusted context, enabling indirect prompt injection through the resources and prompts surfaces (distinct from tool-description poisoning)."
+  author: "ATR (Agent Threat Rules)"
+  categories:
+    - code
+
+prompt_template: |
+  As a professional AI-agent security analyst, precisely detect indirect prompt injection via the MCP resources and prompts surfaces. Content the server exposes as a resource or a prompt template is read by the host LLM as trusted context; if it is assembled from untrusted external data without neutralization, it becomes an injection channel. Require concrete evidence that untrusted data reaches resource/prompt output; only report with evidence.
+
+  ## Vulnerability Definition
+  This vulnerability occurs when an MCP server implements `resources/read`,
+  `resources/list` contents, or `prompts/get` templates by concatenating
+  attacker-influenceable data — fetched web pages, files, database rows, other
+  tools' output — into the returned text without delimiting or sanitizing it, so
+  agent-directed instructions embedded in that data are executed by the host model.
+
+  ## Detection Criteria (require untrusted data reaching resource/prompt output)
+
+  ### 1. Untrusted data in resource contents
+  **Code Patterns:**
+  - Resource handlers returning content built from an external fetch, file, or DB row
+    with no separation between data and instructions.
+
+  ### 2. Untrusted data in prompt templates
+  **Code Patterns:**
+  - `prompts/get` responses that interpolate external / argument-derived text into
+    the message body the host will treat as instructions.
+
+  ### 3. Missing neutralization / provenance
+  **Code Patterns:**
+  - No delimiting, escaping, or explicit "data, not instructions" framing; no
+    stripping of control/zero-width characters or fake role markers from the external
+    content.
+
+  ## Strict Judgment Standards
+  - **Static resources**: Do not report constant, developer-authored resource or
+    prompt text.
+  - **Properly delimited data**: Do not report handlers that clearly fence external
+    content as untrusted data and neutralize control characters.
+  - **User-facing only**: Do not report content returned purely for display that the
+    agent does not consume as context.
+
+  ## Output Requirements
+  Only output when finding concrete resource/prompt injection evidence:
+  - Specific file paths and line numbers
+  - The untrusted source and the resource/prompt output it flows into
+  - Technical analysis: how embedded instructions reach the host model as context
+  - Impact assessment: agent goal hijack, data exfiltration, unwanted tool calls
+  - Remediation: fence external content as data, neutralize control/zero-width
+    characters and role markers, keep instructions server-authored and constant.
+
+  **Strict Requirement: show the concrete untrusted-data-to-context path. Remain silent when no concrete evidence exists.**

data/mcp/mcp_sql_injection.yaml

@@ -0,0 +1,54 @@
+info:
+  id: "mcp_sql_injection"
+  name: "MCP Tool SQL Injection Detection"
+  description: "Detect MCP database tools that build SQL from tool-call arguments via string formatting or concatenation instead of parameterized queries, allowing argument-driven SQL injection."
+  author: "ATR (Agent Threat Rules)"
+  categories:
+    - code
+
+prompt_template: |
+  As a professional AI-agent security analyst, precisely detect SQL-injection vulnerabilities in MCP database tools. The agent controls tool arguments; if they are concatenated into SQL instead of bound as parameters, the MCP server executes attacker-shaped queries. Require a concrete tainted-argument-to-query path; only report with evidence.
+
+  ## Vulnerability Definition
+  SQL injection occurs when an MCP tool composes a query string from a tool argument
+  using f-strings, `+` concatenation, `%`/`.format`, or template interpolation, and
+  executes it against a database, rather than passing the argument as a bound
+  parameter. It also covers unsafe identifier interpolation (table/column names) and
+  NoSQL query-object injection.
+
+  ## Detection Criteria (require a tainted argument reaching a query sink)
+
+  ### 1. String-built query from an argument
+  **Code Patterns:**
+  - Tool argument interpolated into a SQL string that reaches `cursor.execute`,
+    `db.query`, `session.execute(text(...))`, an ORM raw-SQL call, or a driver query
+    method.
+  - Interpolated table/column/order-by identifiers taken from arguments.
+
+  ### 2. Missing parameterization
+  **Code Patterns:**
+  - No placeholder binding (`?`, `$1`, `:name`) for argument values; values embedded
+    directly in the statement.
+
+  ### 3. NoSQL / query-object injection
+  **Code Patterns:**
+  - Argument merged into a Mongo/Elasticsearch query object enabling operator
+    injection (`$where`, `$ne`, script queries).
+
+  ## Strict Judgment Standards
+  - **Parameterized queries**: Do not report code that binds argument values via
+    placeholders / prepared statements.
+  - **Validated identifiers**: Do not report identifier use restricted to an
+    allow-list of known table/column names.
+  - **Constant SQL**: Do not report static queries with no argument influence.
+
+  ## Output Requirements
+  Only output when finding concrete SQL-injection evidence:
+  - Specific file paths and line numbers
+  - The tainted argument and the query sink it reaches
+  - Technical analysis: how crafted input alters the executed query
+  - Impact assessment: data exfiltration, modification, auth bypass
+  - Remediation: use parameterized queries / prepared statements, allow-list
+    identifiers, avoid raw string SQL from arguments.
+
+  **Strict Requirement: show the concrete argument-to-query path. Remain silent when no concrete evidence exists.**

data/mcp/mcp_ssrf.yaml

@@ -0,0 +1,55 @@
+info:
+  id: "mcp_ssrf"
+  name: "MCP Tool Server-Side Request Forgery Detection"
+  description: "Detect MCP tools that fetch a URL, host, or address taken from tool-call arguments without validation, letting the agent (or upstream prompt injection) reach internal services, cloud metadata, or the loopback interface (SSRF)."
+  author: "ATR (Agent Threat Rules)"
+  categories:
+    - code
+
+prompt_template: |
+  As a professional AI-agent security analyst, precisely detect server-side request forgery (SSRF) in MCP server tools. The agent controls tool arguments; if a URL/host argument reaches a network client without allow-listing, the MCP server becomes an SSRF proxy into the trust boundary it runs in. Require a concrete tainted-argument-to-fetch path; only report with evidence.
+
+  ## Vulnerability Definition
+  SSRF occurs when an MCP tool takes a location argument — URL, hostname, IP, port,
+  or a document/webhook reference — and passes it to an HTTP client, socket, DNS
+  resolver, headless browser, or file/URL loader without restricting the
+  destination. An attacker steers the request to `169.254.169.254` (cloud metadata),
+  `127.0.0.1`, internal hostnames, or non-HTTP schemes.
+
+  ## Detection Criteria (require a tainted argument reaching a network sink)
+
+  ### 1. Unvalidated URL/host argument to a network client
+  **Code Patterns:**
+  - Tool argument flows into `requests.get`, `httpx`, `urllib`, `fetch`, `axios`,
+    `net.Dial`, a headless browser `goto`, or an image/document loader.
+  - No scheme allow-list, no host allow-list, no block of private / link-local /
+    loopback ranges.
+
+  ### 2. Metadata / internal-service reachability
+  **Code Patterns:**
+  - Requests that can resolve to `169.254.169.254`, `metadata.google.internal`,
+    `localhost`, RFC1918 ranges, or container service names.
+
+  ### 3. Redirect / scheme abuse
+  **Code Patterns:**
+  - Following redirects to attacker-chosen hosts, or accepting `file://`, `gopher://`,
+    `dict://`, or similar non-HTTP schemes.
+
+  ## Strict Judgment Standards
+  - **Fixed endpoints**: Do not report calls to a constant, developer-controlled URL
+    with no argument influence on the destination.
+  - **Properly allow-listed fetchers**: Do not report code that validates scheme and
+    host against an allow-list and blocks private ranges before the request.
+  - **Client-side only**: Do not report URLs that are merely returned to the user and
+    never fetched server-side.
+
+  ## Output Requirements
+  Only output when finding concrete SSRF evidence:
+  - Specific file paths and line numbers
+  - The tainted argument and the network sink it reaches
+  - Technical analysis: which internal destinations become reachable
+  - Impact assessment: metadata theft, internal service access, port scanning
+  - Remediation: allow-list scheme and host, resolve-then-check against private
+    ranges, disable redirects, drop non-HTTP schemes.
+
+  **Strict Requirement: show the concrete argument-to-request path. Remain silent when no concrete evidence exists.**

data/mcp/mcp_tool_rug_pull.yaml

@@ -0,0 +1,56 @@
+info:
+  id: "mcp_tool_rug_pull"
+  name: "MCP Tool Rug-Pull / Silent Redefinition Detection"
+  description: "Detect MCP servers whose tool definitions, descriptions, or behavior can change after initial client approval (rug-pull), so a benign-looking tool is later mutated into a malicious one without re-consent."
+  author: "ATR (Agent Threat Rules)"
+  categories:
+    - code
+
+prompt_template: |
+  As a professional AI-agent security analyst, precisely detect tool rug-pull / silent-redefinition vulnerabilities in MCP server code. A rug-pull hides its payload in time: the tool the client approves is not the tool that later runs. Require concrete evidence that tool-facing metadata or behavior is mutable post-registration; only report with evidence.
+
+  ## Vulnerability Definition
+  A rug-pull occurs when an MCP server can alter a tool's `description`,
+  `inputSchema`, annotations, or executed behavior AFTER the client has listed and
+  approved it — for example serving benign descriptions on first `tools/list`, then
+  swapping in adversarial instructions or a different implementation on a later call
+  or after a version/day/counter check. The host agent keeps trusting the original
+  approval.
+
+  ## Detection Criteria (require concrete evidence of post-approval mutation)
+
+  ### 1. Time / state-gated tool metadata
+  **Code Patterns:**
+  - Tool `description` or parameter docs built from a mutable source (remote fetch,
+    database, file re-read on each request) rather than a constant.
+  - Conditional branches keyed on date, request count, an install flag, or a remote
+    kill-switch that select a different description or handler.
+
+  ### 2. Deferred or dynamic tool implementation
+  **Code Patterns:**
+  - Tool handler resolved at call time from a network response, a downloaded module,
+    or a value that can change between registration and invocation.
+  - Re-registration of the same tool name with different behavior after startup.
+
+  ### 3. Divergence between advertised and executed behavior
+  **Code Patterns:**
+  - The handler performs actions (network, file, exec) not implied by the
+    description the client approved.
+
+  ## Strict Judgment Standards
+  - **Legitimate config reload**: Do not report ordinary hot-reload that keeps tool
+    semantics stable and re-notifies the client of changes.
+  - **Static descriptions**: Do not report constant, developer-authored descriptions.
+  - **Feature flags**: Do not report flags that gate availability but not a tool's
+    advertised meaning.
+
+  ## Output Requirements
+  Only output when finding concrete rug-pull evidence:
+  - Specific file paths and line numbers
+  - The mutable source and the code path that changes tool metadata or behavior
+  - Technical analysis: how the approved definition diverges from what later runs
+  - Impact assessment: what the mutated tool could do post-approval
+  - Remediation: pin tool definitions, re-request consent on change, sign/verify
+    the tool manifest, forbid remote/mutable description sources.
+
+  **Strict Requirement: show the concrete post-approval mutation path. Remain silent when no concrete evidence exists.**