@zivis/mcp 0.1.8 → 0.1.11

package/dist/pattern-packs/zivis-public-0.2.0/capsules/retrieval/context-injection-no-validator.yaml

@@ -0,0 +1,348 @@
+# Capsule: RAG context injection — retrieved content reaches the model without validation
+# Spec: docs/specs/PATTERN-MATCHING-LIBRARY-V1.md
+# Plan: docs/plans/LOCAL-REPO-GRAPH-IMPLEMENTATION.md
+# Schema: schemas/pattern-detection-card.schema.json
+
+id: retrieval.context-injection-no-validator
+slug: context-injection-no-validator
+version: 0.1.0
+category: retrieval
+title: Retrieval Context Injection — No Validator Between Retriever and Model
+headline: Retrieved Content Flows Into the LLM With Nothing Inspecting It First
+
+description: >
+  Detects retrieval-augmented generation (RAG) flows where the output of a
+  retriever (vector store, search index, document loader) is passed directly
+  into the model call with no fact-validator, source-attribution check, or
+  content sanitizer in between. Retrieval becomes a transparent injection
+  channel: anyone who can write to the knowledge base — directly, via a
+  scraping job, or via a tool the agent itself calls — can steer the model.
+
+detection_tier: public
+scoring_tier: proprietary
+
+applicable_languages:
+  - typescript
+  - javascript
+  - python
+
+relevance_filter:
+  any_of:
+    # LangChain / LlamaIndex RAG stacks
+    - dependency: langchain
+      direct_only: true
+    - dependency: "@langchain/core"
+      direct_only: true
+    - dependency: "@langchain/openai"
+      direct_only: true
+    - dependency: "@langchain/anthropic"
+      direct_only: true
+    - dependency: "@langchain/community"
+      direct_only: true
+    - dependency: llamaindex
+      direct_only: true
+    - dependency: "llama-index"
+      direct_only: true
+    # Manual RAG: any LLM SDK + a vector store / retrieval client
+    - dependency: openai
+      direct_only: true
+    - dependency: "@anthropic-ai/sdk"
+      direct_only: true
+    - dependency: anthropic
+      direct_only: true
+    - dependency: "@pinecone-database/pinecone"
+      direct_only: true
+    - dependency: pinecone-client
+      direct_only: true
+    - dependency: "@qdrant/js-client-rest"
+      direct_only: true
+    - dependency: qdrant-client
+      direct_only: true
+    - dependency: weaviate-ts-client
+      direct_only: true
+    - dependency: weaviate-client
+      direct_only: true
+    - dependency: chromadb
+      direct_only: true
+    - dependency: "@elastic/elasticsearch"
+      direct_only: true
+    - dependency: elasticsearch
+
+strategies:
+  # AST as architectural evidence (NOT a vulnerability claim) — does this
+  # codebase even have a retrieval→LLM call shape? If it doesn't, the
+  # pattern can't apply.
+  - code: AST
+    language: typescript
+    expression: |
+      rule:
+        any:
+          # LangChain idioms
+          - pattern: $RETRIEVER.invoke($$$)
+          - pattern: $RETRIEVER.getRelevantDocuments($$$)
+          - pattern: new RetrievalQAChain($$$)
+          - pattern: RetrievalQAChain.fromLLM($$$)
+          - pattern: createRetrievalChain($$$)
+          # LlamaIndex
+          - pattern: $INDEX.asQueryEngine($$$)
+          - pattern: $QUERY_ENGINE.query($$$)
+          # Manual RAG: vector-store similarity search feeding a model call
+          - pattern: $STORE.similaritySearch($$$)
+          - pattern: $STORE.similaritySearchWithScore($$$)
+    evidence_fields: [file_path, line_span, symbol]
+    confidence_weight: 0.40
+
+  - code: AST
+    language: python
+    expression: |
+      rule:
+        any:
+          # LangChain
+          - pattern: $RETRIEVER.invoke($$$)
+          - pattern: $RETRIEVER.get_relevant_documents($$$)
+          - pattern: RetrievalQA.from_chain_type($$$)
+          - pattern: create_retrieval_chain($$$)
+          # LlamaIndex
+          - pattern: $INDEX.as_query_engine($$$)
+          - pattern: $QUERY_ENGINE.query($$$)
+          # Manual RAG: vector-store similarity search
+          - pattern: $STORE.similarity_search($$$)
+          - pattern: $STORE.similarity_search_with_score($$$)
+    evidence_fields: [file_path, line_span, symbol]
+    confidence_weight: 0.40
+
+  # GRAPH strategy — forward-compatible. Matcher v1 doesn't evaluate
+  # graph predicates yet (per Phase 3 v1 in LOCAL-REPO-GRAPH-IMPLEMENTATION),
+  # but writing it now means the card "lights up" when the matcher catches
+  # up, without re-authoring.
+  - code: GRAPH
+    expression: |
+      retrieval_node_returns_documents
+      AND llm_call_node_consumes_documents
+      AND NO_NODE_BETWEEN(retrieval_node, llm_call_node) matches
+        (validator | fact_checker | source_attribution | content_sanitizer)
+    evidence_fields: [graph_path, file_spans, node_ids]
+    confidence_weight: 0.30
+
+  # META — does the codebase declare any of the controls that would make
+  # this pattern safe? Absence is what we care about.
+  - code: META
+    expression:
+      none_of_controls:
+        - fact_validator_present
+        - source_attribution_present
+    evidence_fields: [missing_controls]
+    confidence_weight: 0.30
+
+  # INFER — the host LLM (Claude in the IDE) gets the actual source spans
+  # and decides whether what looks like RAG truly has no validator. This is
+  # the lane we want most matches to land in: ZIVIS surfaces the candidate,
+  # the frontier model validates against the code.
+  - code: INFER
+    expression: prompt_id:retrieval.context-injection-no-validator.identify
+    evidence_fields: [llm_rationale]
+    confidence_weight: 0.20
+    trusted: false
+
+# Two deterministic strategies must fire for a trusted-lane match. AST
+# alone won't promote — it's just "there is RAG-shaped code." AST + META
+# (controls absent) WILL promote. GRAPH lights up later for free.
+required_evidence_count: 2
+
+control_negations:
+  - "presence_of(fact_validator_present)"
+  - "presence_of(source_attribution_present)"
+
+threats:
+  - title: Indirect prompt injection via retrieved corpus
+    stride: [tampering, elevation_of_privilege]
+    description: >
+      An attacker who can write to the retrieval corpus — a public web page
+      indexed by a scraper, a Confluence space synced into the vector store,
+      a customer-uploaded document, or a tool the agent uses to fetch
+      content — embeds instructions that the model treats as authoritative
+      because they arrive inside the "trusted" retrieval channel. The model
+      executes those instructions or leaks data based on them. With no
+      validator inspecting the retrieved text, the system has no defense
+      between the corpus and the model.
+    remediation: >
+      Insert a validation step between retriever and model that (a) checks
+      retrieved content for prompt-injection patterns, (b) requires
+      source-attribution metadata before content can influence answers, and
+      (c) rate-limits or content-flags low-trust sources. Patterns like
+      guardrails-ai, NeMo Guardrails, Lakera Guard, or a custom
+      `validateRetrievedContent()` boundary are all valid; the requirement
+      is that *some* boundary exists between corpus and model.
+
+  - title: Sensitive-data exfiltration via crafted retrieval queries
+    stride: [information_disclosure]
+    description: >
+      An attacker who can influence the retrieval query — directly or via a
+      preceding LLM step that re-writes the query — pulls documents the
+      requesting user should not see (other tenants' data, internal-only
+      pages indexed by mistake, PII-laden support tickets). The model then
+      surfaces that content in the response. Without source-attribution and
+      access checks at the retrieval boundary, the model becomes an
+      authorization bypass.
+    remediation: >
+      Enforce access control at the retrieval layer, not just at the API
+      layer. Tag every indexed document with the access scope it inherits
+      from its source system, and filter retrieval by the requesting
+      user's scope before content reaches the model. Treat the retriever
+      as a privileged data path — same scrutiny as any other query.
+
+  - title: Long-running drift from poisoned corpus
+    stride: [tampering, repudiation]
+    description: >
+      A single poisoned document indexed months ago continues to surface in
+      relevant queries indefinitely. The model's behavior drifts in ways
+      that are hard to attribute to a specific bug because the cause is in
+      the corpus, not the code. With no audit log of which retrieved
+      documents influenced which responses, post-incident investigation
+      cannot trace bad behavior back to its source.
+    remediation: >
+      Log every retrieval — query, returned document IDs, document hashes,
+      source attribution — alongside the LLM call it fed. Periodically
+      revalidate corpus contents against current trust assumptions
+      (re-classify documents from sources that have been compromised or
+      whose access policy changed).
+
+fixtures:
+  positive:
+    - "fixtures/positive/context-injection-no-validator/langchain_rag_chain_no_validator_typescript"
+    - "fixtures/positive/context-injection-no-validator/llamaindex_query_engine_no_validator_python"
+    - "fixtures/positive/context-injection-no-validator/manual_pinecone_to_openai_typescript"
+  negative:
+    - "fixtures/negative/context-injection-no-validator/guardrails_validator_present_python"
+    - "fixtures/negative/context-injection-no-validator/source_attribution_check_typescript"
+
+lifecycle: draft
+owner: platform-threat-modeling
+tags:
+  - retrieval
+  - rag
+  - prompt-injection
+  - context-injection
+  - corpus-poisoning
+  - agentic-ai
+
+sensitivity_level: customer_safe
+allowed_execution_modes:
+  - local_only
+  - local_model
+  - hybrid_cloud_eval
+
+safe_summary: >
+  The codebase has a retrieval-augmented generation (RAG) shape — content
+  is pulled from a vector store, search index, or document loader and
+  passed to the LLM — but there's no validator, sanitizer, or
+  source-attribution check between the retriever and the model. Anyone
+  who can write to the retrieval corpus can steer the model: an indexed
+  web page, a synced Confluence space, a customer-uploaded document, or
+  a tool the agent itself fetches from. The fix is to put a boundary
+  between corpus and model — a guardrails library, a custom validator,
+  or per-document source-attribution that the model is required to
+  surface in its answers.
+
+detect_when: >
+  A retriever call (`retriever.invoke`, `similaritySearch`, query engine,
+  retrieval chain) is followed by an LLM call within the same handler or
+  function, and the path between them contains no recognizable validator
+  or source-attribution step. Most common in chat / Q&A / "ask the docs"
+  applications.
+
+risk_hints:
+  - "Retrieval is a privileged data path — anything in the corpus is implicitly trusted by the model"
+  - "Prompt injection embedded in a web page or shared doc survives indefinitely until the document is re-indexed"
+  - "Query rewriting (HyDE, multi-query) compounds the problem — the rewritten query is itself an LLM output"
+  - "Access control at the API layer doesn't help if the retriever pulls from a corpus indexed under different rules"
+  - "Logging the LLM input/output without logging the retrieved documents leaves the actual injection invisible"
+
+architectural_signals:
+  - "Retriever / vector store / search index call returns documents"
+  - "Documents are concatenated into a system or user prompt slot"
+  - "No intermediate function whose name suggests validation, sanitization, or fact-checking"
+  - "No source-attribution requirement in the prompt template"
+
+model_task_prompt_ref: prompts/retrieval/context-injection-no-validator/identify.md
+
+expected_output_schema:
+  type: object
+  required: [verdict, validator_location, evidence_spans]
+  properties:
+    verdict:
+      type: string
+      enum: [no_validator_present, validator_present, partial_validator, unclear]
+    validator_location:
+      type: string
+      enum: [pre_retrieval, between_retriever_and_model, post_model, none, multiple]
+    rationale:
+      type: string
+    corpus_sources:
+      type: array
+      description: "Best-effort enumeration of where the retrieved content comes from"
+      items:
+        type: string
+    blast_radius:
+      type: string
+      enum: [single_endpoint, route_family, service_wide, agent_wide, unclear]
+    recommended_controls:
+      type: array
+      items:
+        type: string
+        enum:
+          - guardrails_library
+          - custom_content_validator
+          - source_attribution_in_prompt
+          - per_document_access_control
+          - retrieval_audit_log
+          - none
+    evidence_spans:
+      type: array
+      items:
+        type: object
+        required: [file]
+        properties:
+          file: { type: string }
+          start_line: { type: integer }
+          end_line: { type: integer }
+          note: { type: string }
+
+minimum_context_required:
+  lines: 120
+  symbols:
+    - retriever
+    - invoke
+    - similarity_search
+    - similaritySearch
+    - query_engine
+    - asQueryEngine
+    - RetrievalQA
+    - create_retrieval_chain
+
+related_patterns:
+  - prompting.user-input-in-system-prompt
+  - agents.tool-dispatch-from-llm-output
+
+repair_contract:
+  allowed:
+    - "Insert a validator step between retriever and model call"
+    - "Add source-attribution requirement to the prompt template"
+    - "Adopt guardrails-ai / NeMo Guardrails / Lakera Guard or equivalent"
+    - "Implement per-document access control at the retrieval boundary"
+    - "Add structured logging of retrieved-document IDs alongside LLM calls"
+  forbidden:
+    - "Removing retrieval entirely without first replacing the answering path"
+    - "Validating only LLM output instead of retrieved content (treats the wrong stage)"
+    - "Hand-rolling regex injection filters as the sole defense (well-known to be bypassable)"
+
+validation_contract:
+  requires_tests_pass: false
+  requires_static_rules:
+    - validator_node_present_between_retrieval_and_llm
+    - retrieval_audit_log_present
+
+unsafe_to_expose_fields:
+  - internal_rubric
+  - golden_transcripts
+  - exploit_templates

package/dist/pattern-packs/zivis-public-0.2.0/capsules/security/late-org-filter.yaml

@@ -0,0 +1,266 @@
+# Capsule: Late org-filter — cross-tenant leak via presentation-time scoping
+# Spec: docs/specs/PATTERN-MATCHING-LIBRARY-V1.md
+# Plan: docs/plans/LOCAL-REPO-GRAPH-IMPLEMENTATION.md
+# Schema: schemas/pattern-detection-card.schema.json
+
+id: security.late-org-filter
+slug: late-org-filter
+version: 0.1.0
+category: security
+title: Late Org Filter
+headline: Tenant Scoping Applied After the Query, Not Inside It
+description: >
+  Detects multi-tenant code paths where org/tenant filtering happens at the
+  presentation layer (response loop, stream emit, response shaping) instead
+  of inside the data query. Any race, error path, or partial response that
+  reaches the wire before the filter fires leaks rows across tenants.
+
+detection_tier: public
+scoring_tier: proprietary
+
+applicable_languages:
+  - typescript
+  - javascript
+  - python
+  - go
+
+relevance_filter:
+  any_of:
+    - dependency: express
+      direct_only: true
+    - dependency: fastify
+      direct_only: true
+    - dependency: hono
+      direct_only: true
+    - dependency: "@nestjs/core"
+      direct_only: true
+    - dependency: fastapi
+      direct_only: true
+    - dependency: flask
+      direct_only: true
+    - dependency: "django"
+      direct_only: true
+    - dependency: "github.com/gin-gonic/gin"
+      direct_only: true
+    - dependency: "github.com/labstack/echo/v4"
+      direct_only: true
+  none_of:
+    # If the project clearly isn't multi-tenant, skip — no benefit, lots of noise.
+    - evidence: "single_tenant_only_marker"
+
+strategies:
+  - code: AST
+    language: typescript
+    expression: |
+      rule:
+        any:
+          # Filter applied to a query result then sent — classic shape.
+          - pattern: $ROWS.filter($_ => $_.orgId === $$$)
+          - pattern: $ROWS.filter($_ => $_.org_id === $$$)
+          - pattern: $ROWS.filter($_ => $_.tenantId === $$$)
+          # Per-row tenant guard inside a loop — the SSE / iterator variant.
+          - pattern: |
+              if ($R.orgId === $$$) {
+                $$$
+              }
+          - pattern: |
+              if ($R.org_id === $$$) {
+                $$$
+              }
+    evidence_fields: [file_path, line_span, symbol]
+    confidence_weight: 0.35
+
+  - code: AST
+    language: python
+    expression: |
+      rule:
+        any:
+          - pattern: |
+              rows = $QUERY($$$)
+              filtered = [r for r in rows if r.org_id == $REQ.org_id]
+          - pattern: |
+              for row in $QUERY($$$):
+                if row.org_id == request.org_id:
+                  yield row
+    evidence_fields: [file_path, line_span, symbol]
+    confidence_weight: 0.35
+
+  - code: GRAPH
+    expression: |
+      query_call_returns_rows
+      AND filter_predicate_references(req_org_id OR session_org_id)
+      AND filter_executes_AFTER(query_call) IN response_handler_or_stream_emit
+      AND query_call.where_clause DOES_NOT include org_id
+    evidence_fields: [graph_path, file_spans, node_ids]
+    confidence_weight: 0.30
+
+  - code: META
+    expression:
+      none_of_controls:
+        - row_level_security_policy
+        - prisma_extension_or_middleware_attaching_org_filter
+    evidence_fields: [missing_controls]
+    confidence_weight: 0.20
+
+  - code: INFER
+    expression: prompt_id:security.late-org-filter.identify
+    evidence_fields: [llm_rationale]
+    confidence_weight: 0.15
+    trusted: false
+
+required_evidence_count: 2
+
+control_negations:
+  - "presence_of(row_level_security_policy)"
+  - "presence_of(query_helper_with_implicit_org_scope)"
+  - "presence_of(prisma_extension_or_middleware_attaching_org_filter)"
+
+threats:
+  - title: Cross-tenant data leak via SSE / stream pre-filter window
+    stride: [information_disclosure, elevation_of_privilege]
+    description: >
+      In a streaming or async-iterator response, the underlying query returns
+      rows from all tenants and the per-emit filter rejects mismatches. A
+      brief window where rows are buffered, logged, traced, or partially
+      rendered before the filter executes can leak data across tenants. This
+      is the SSE / queue/stream variant of the pattern.
+    remediation: >
+      Push the org/tenant predicate into the data layer — RLS, query helpers,
+      ORM middleware. Make every query mandatorily org-scoped at the boundary;
+      treat presentation-layer filters as defense in depth, never the primary
+      barrier.
+  - title: Cross-tenant leak via error path or partial response
+    stride: [information_disclosure]
+    description: >
+      An exception inside the post-query filter loop returns the unfiltered
+      buffer or a serialization mid-state. Other tenants' rows reach the
+      wire because the only org check sits past the failure point.
+    remediation: >
+      Same control — RLS or query-time scoping. Plus: serialize the response
+      body only after filtering completes; on filter error, return a
+      structured error with no payload.
+  - title: Logged or traced rows expose other tenants
+    stride: [information_disclosure, repudiation]
+    description: >
+      Observability hooks (request logger, tracer, metrics) often capture the
+      raw query result before the presentation-layer filter runs. Other
+      tenants' identifiers, names, or PII land in logs the requesting tenant
+      should never have seen.
+    remediation: >
+      Either log only post-filter results, or — better — make the query
+      itself org-scoped so the unfiltered result never exists.
+
+fixtures:
+  positive:
+    - "fixtures/positive/late-org-filter/express_sse_post_filter_typescript"
+    - "fixtures/positive/late-org-filter/fastapi_iterator_post_filter_python"
+  negative:
+    - "fixtures/negative/late-org-filter/prisma_middleware_org_scope"
+    - "fixtures/negative/late-org-filter/postgres_rls_enabled"
+
+lifecycle: draft
+owner: platform-threat-modeling
+tags:
+  - multi-tenant
+  - cross-tenant-leak
+  - data-scoping
+  - sse
+  - stream
+
+sensitivity_level: customer_safe
+allowed_execution_modes:
+  - local_only
+  - local_model
+  - hybrid_cloud_eval
+
+safe_summary: >
+  Tenant filtering applied after the query — at the response loop, the SSE
+  emit, or the stream iterator — instead of inside the query. Any error,
+  race, observability hook, or partial response that fires before the filter
+  reaches the wire leaks rows across tenants. The fix is to push org/tenant
+  scoping down to the data layer (RLS, query helpers, ORM middleware) so the
+  unfiltered set never exists in the first place.
+
+detect_when: >
+  A handler, stream, or async iterator runs a data query, then filters the
+  result by `request.orgId` (or a session org) before responding — and the
+  query itself doesn't include the org predicate. Multi-tenant routes only.
+
+risk_hints:
+  - The bug class behind a meaningful share of cross-tenant SaaS incidents
+  - SSE / queue / WebSocket variants are the hardest to spot because the filter looks "inside" the loop
+  - Logs and traces often capture the unfiltered set even when the response itself is clean
+  - Tests often pass because they only run with a single tenant in the test database
+
+architectural_signals:
+  - Query call followed by an explicit filter referencing a request/session org id
+  - SSE or async iterator that yields events conditional on a tenant match
+  - No row-level security policy, no implicit-org-scope helper, no ORM middleware
+
+model_task_prompt_ref: prompts/security/late-org-filter/identify.md
+
+expected_output_schema:
+  type: object
+  required: [verdict, scope_location, evidence_spans]
+  properties:
+    verdict:
+      type: string
+      enum: [late_filter_present, scoped_at_query, partial_scope, unclear]
+    scope_location:
+      type: string
+      enum: [data_layer, query_layer, presentation_layer, multiple, none]
+    rationale:
+      type: string
+    blast_radius:
+      type: string
+      enum: [single_endpoint, route_family, service_wide, unclear]
+    recommended_controls:
+      type: array
+      items:
+        type: string
+        enum: [row_level_security, query_helper, orm_middleware, repository_pattern_with_org_scope, none]
+    evidence_spans:
+      type: array
+      items:
+        type: object
+        required: [file]
+        properties:
+          file: { type: string }
+          start_line: { type: integer }
+          end_line: { type: integer }
+          note: { type: string }
+
+minimum_context_required:
+  lines: 100
+  symbols:
+    - orgId
+    - org_id
+    - tenant_id
+    - filter
+    - SSE
+    - stream
+
+related_patterns:
+  - security.idor-via-direct-id
+  - security.broken-object-level-authz
+
+repair_contract:
+  allowed:
+    - Push org/tenant scoping into the query (where clause, RLS, ORM middleware)
+    - Introduce a repository wrapper that mandates org_id on every method
+    - Add a Postgres row-level security policy
+    - Keep the presentation-layer filter as defense in depth IN ADDITION TO the data-layer scope
+  forbidden:
+    - Removing the presentation-layer filter without first introducing a data-layer scope (regresses safety)
+    - Treating the patch as complete after only fixing the immediate route — the bug class is structural
+
+validation_contract:
+  requires_tests_pass: false
+  requires_static_rules:
+    - data_layer_org_scope_present_after_patch
+    - no_unscoped_query_remains_in_route_handler
+
+unsafe_to_expose_fields:
+  - internal_rubric
+  - golden_transcripts
+  - exploit_templates

package/dist/pattern-packs/zivis-public-0.2.0/controls/external_validator_on_facts.yaml

@@ -0,0 +1,37 @@
+# Control: external_validator_on_facts
+# Referenced by:
+#   - prompting.self-consistency-no-isolation (META: none_of_controls)
+#
+# An external (non-LLM) check that the aggregated answer is factually
+# consistent — a SQL query, an API call, a regex against ground truth, etc.
+
+id: external_validator_on_facts
+description: >
+  An external, non-LLM check applied to the aggregated answer before it's
+  acted on. Common shapes: factCheck()/validateFacts() helpers, schema
+  validation, lookup against a trusted store.
+
+applicable_languages:
+  - typescript
+  - javascript
+  - python
+
+detection:
+  - language: typescript
+    rule:
+      any:
+        - pattern: factCheck($$$)
+        - pattern: validateFacts($$$)
+        - pattern: validateAnswer($$$)
+        - pattern: $_.factCheck($$$)
+        - pattern: $_.validate($$$)
+  - language: python
+    rule:
+      any:
+        - pattern: fact_check($$$)
+        - pattern: validate_facts($$$)
+        - pattern: validate_answer($$$)
+        - pattern: $_.validate_against_ground_truth($$$)
+
+owner: platform-threat-modeling
+lifecycle: draft