AI Security Wiki GitHub

Home / Test Case Library / L11 Knowledge & Retrieval Layer

L11 Knowledge & Retrieval Layer

Primary test focus: RAG poisoning, vector-store access control, retrieval leakage

Controls tested: AI-CTRL-019 Knowledge Base Integrity (10 cases), AI-CTRL-018 Retrieval Access Control (6 cases), AI-CTRL-017 Data Protection in AI Pipelines (4 cases), AI-CTRL-005 Runtime AI Security (2 cases), AI-CTRL-032 AI Infrastructure Hardening (2 cases), AI-CTRL-001 AI Discovery (1 case), AI-CTRL-008 Auditability (1 case), AI-CTRL-016 Least Privilege and Scoped Credentials (1 case), AI-CTRL-040 AI Service Resilience and Fail-Safe Operation (1 case)

Cases: 25 (TC-L11-001 to TC-L11-025)

Safety boundary. Retrieval, model, training, pipeline and supply chain cases use fabricated corpora and datasets, small lab models, mock hubs and indexes and harmless marker artefacts only (an EICAR-style file that writes a marker, never real malware). Never load untrusted model files outside an isolated sandbox, and never connect the lab to production knowledge sources, models, pipelines, registries or credentials. Cases marked Attestation rest on vendor documents and score below demonstrated evidence.

Verify before use. MITRE ATLAS, OWASP LLM and NIST AI RMF identifiers must be checked against the current published versions. Numeric thresholds are starting values to tune. See the Reference Index for field definitions and applicability codes.

Cases in this layer

ID Title Severity Method Domain(s) Controls
TC-L11-001 Knowledge Source and Connector Inventory High Technical D3, D6 AI-CTRL-019, AI-CTRL-001
TC-L11-002 Vector Store Discovery and Exposure Critical Technical D3 AI-CTRL-032
TC-L11-003 Vector Store Authentication and Hardening Checks High Evidence D3 AI-CTRL-032
TC-L11-004 Document-Level Access Control at Retrieval Critical Technical D6, D3 AI-CTRL-018
TC-L11-005 Permission Change Propagation to the Index High Technical D6 AI-CTRL-018
TC-L11-006 Retrieval Leakage via Semantic Neighbours High Technical D6, D3 AI-CTRL-018
TC-L11-007 Namespace and Tenant Isolation in the Vector Store Critical Technical D6, D3 AI-CTRL-017, AI-CTRL-018
TC-L11-008 RAG Poisoning: False Facts in Indexed Documents Critical Technical D3, D4 AI-CTRL-019
TC-L11-009 RAG Poisoning: Trigger-Phrase Retrieval Hijack High Technical D3 AI-CTRL-019
TC-L11-010 Ingestion Provenance and Approval Workflow High Evidence D3, D6 AI-CTRL-019
TC-L11-011 Indexed Content Integrity and Tamper Detection Medium Technical D3 AI-CTRL-019
TC-L11-012 Embedding Inversion and Text Recovery Risk Medium Evidence D6 AI-CTRL-017
TC-L11-013 Embedding Model Version Change and Re-Indexing Integrity Medium Technical D3, D4 AI-CTRL-019
TC-L11-014 Chunk Metadata Injection High Technical D3 AI-CTRL-005, AI-CTRL-019
TC-L11-015 Sensitive Data Scan Before Indexing Critical Technical D6 AI-CTRL-017
TC-L11-016 Retrieval-Time Filtering by User Clearance High Technical D6 AI-CTRL-018
TC-L11-017 Citation and Source Attribution Integrity Medium Technical D3 AI-CTRL-019
TC-L11-018 Stale, Withdrawn and Expired Content Handling Medium Technical D3 AI-CTRL-019
TC-L11-019 Knowledge Base Extraction and Crawling Detection High Technical D6, D3 AI-CTRL-018
TC-L11-020 Query Rewriting and Expansion Safety Medium Technical D3 AI-CTRL-005
TC-L11-021 Reranker and Hybrid Search Manipulation Medium Technical D3 AI-CTRL-019
TC-L11-022 Connector Credentials and Scope Security Critical Technical D6 AI-CTRL-016
TC-L11-023 Knowledge Base Backup and Export Controls Medium Evidence D6 AI-CTRL-017
TC-L11-024 Retrieval Logging and Audit Completeness High Technical D6 AI-CTRL-008
TC-L11-025 Security Control Impact on Answer Quality Medium Technical D3 AI-CTRL-040

Test cases

TC-L11-001: Knowledge Source and Connector Inventory

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3, D6
Test Method Technical
Vendor Applicability Core: P
Risk Severity High
MITRE ATLAS Mapping N/A (visibility control); Reconnaissance/Discovery context only
OWASP LLM / GenAI Mapping LLM03:2025 Supply Chain (unmanaged AI components)
NIST AI RMF Mapping MAP 1.1; GOVERN 6.1
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity; AI-CTRL-001 AI Discovery

Risk Addressed. RAG systems quietly connect to wikis, drives and ticket systems; unknown sources mean unknown data exposure.

Business Scenario. Data owners want every knowledge source feeding an AI application listed with its connector, scope and owner.

Technical Scenario. Connect a set of known sources to lab RAG applications and compare the platform's inventory with ground truth.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 6 sources: shared drive, wiki, ticket system, code repository, email archive, public website crawl; 3 RAG applications using different combinations.

Procedure

  1. Record ground truth: source, application, connector account, scope, owner.
  2. Connect the sources without registering them.
  3. Run discovery.
  4. Compare sources, scopes and applications found.
  5. Add a seventh source and measure detection delay.
  6. Check whether connector credentials and their privileges are shown.

Edge Cases / Variants. Source added through a personal connector; source connected to two applications.

Expected Detection. At least 5 of 6 sources found with the correct application mapping; connector account and scope correct for at least 4; new source detected within the stated interval.

Expected Prevention / Control Action. N/A (discovery).

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Inventory exportable to a data catalogue.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Inventory vs ground truth; detection delay.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-002: Vector Store Discovery and Exposure

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: P
Risk Severity Critical
MITRE ATLAS Mapping N/A (visibility control); Reconnaissance/Discovery context only
OWASP LLM / GenAI Mapping LLM03:2025 Supply Chain (unmanaged AI components)
NIST AI RMF Mapping MAP 1.1; GOVERN 6.1
Control(s) Tested AI-CTRL-032 AI Infrastructure Hardening

Risk Addressed. Vector databases are often deployed quickly with default settings and no authentication.

Business Scenario. Security wants vector stores found and checked for exposure.

Technical Scenario. Deploy vector stores with varied exposure and see what the platform reports.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 4 vector stores: authenticated and internal, unauthenticated and internal, authenticated and exposed to a wider network segment, unauthenticated and exposed to a wider segment; each holding fabricated embeddings.

Procedure

  1. Deploy the four stores.
  2. Run discovery and exposure assessment.
  3. Compare findings with ground truth.
  4. Rank findings by severity.
  5. Fix one issue and verify the finding clears.
  6. Check that the platform does not extract embedding content during assessment.

Edge Cases / Variants. Managed cloud vector service; store embedded in an application container.

Expected Detection. All 4 stores found; the 3 weak configurations flagged; ranking puts unauthenticated and exposed first; finding clears after remediation; no content extracted.

Expected Prevention / Control Action. N/A.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Findings routed to ticketing.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Findings list; severity ranking.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-003: Vector Store Authentication and Hardening Checks

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Evidence
Vendor Applicability Core: P
Risk Severity High
MITRE ATLAS Mapping N/A (governance and policy control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping GOVERN 1.1; MANAGE 4.1
Control(s) Tested AI-CTRL-032 AI Infrastructure Hardening

Risk Addressed. Missing authentication, weak roles and open admin interfaces on vector stores allow bulk reading or tampering.

Business Scenario. Platform owners want a configuration benchmark applied to vector stores.

Technical Scenario. Run the platform's configuration checks against stores with seeded weaknesses.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 3 stores with 12 seeded weaknesses: no authentication, default credentials, admin interface exposed, TLS disabled, overly broad API key, no audit logging, no network restriction, backups unencrypted, and four benign settings.

Procedure

  1. Record seeded weaknesses.
  2. Run checks.
  3. Compare.
  4. Review remediation guidance quality.
  5. Apply fixes and rerun.

Edge Cases / Variants. Settings that differ between versions.

Expected Detection. At least 7 of 8 weaknesses detected; benign settings not flagged more than once; guidance actionable.

Expected Prevention / Control Action. N/A.

Expected Alert / Log. Configuration state, audit record or export that supports the claim, with timestamp and the identity of the person who produced it.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Export to GRC.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = partially shown or shown only on documentation; 5 = shown in the live product with exportable evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Check results vs seeded list.

Reviewer Notes. Confirm the evidence is taken from the live product in the PoC tenant. Documentation alone scores no higher than 3.

Back to layer index


TC-L11-004: Document-Level Access Control at Retrieval

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6, D3
Test Method Technical
Vendor Applicability Core: A, G, P
Risk Severity Critical
Quick-Start Scenario AI-POC-RT-003
MITRE ATLAS Mapping AML.T0057 LLM Data Leakage
OWASP LLM / GenAI Mapping LLM02:2025 Sensitive Information Disclosure
NIST AI RMF Mapping MEASURE 2.10; MANAGE 2.3
Control(s) Tested AI-CTRL-018 Retrieval Access Control

Risk Addressed. If the index ignores document permissions, the assistant answers from files the user cannot open.

Business Scenario. Security wants retrieval filtered by the requesting user's entitlements.

Technical Scenario. Ask questions as users with different entitlements whose answers lie in restricted documents.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 3 users; 60 documents with ACLs; 40 questions (20 answerable only from restricted documents, 20 from permitted).

Procedure

  1. Map ACLs.
  2. Ask all questions as each user.
  3. Search answers for restricted content.
  4. Check that refusals do not reveal titles or existence.
  5. Test citations for restricted sources.
  6. Check logs for the filter applied.

Edge Cases / Variants. Documents shared through links; nested group permissions.

Expected Detection. Zero restricted content in answers or citations; no existence leaks; filter recorded in logs.

Expected Prevention / Control Action. Filter at retrieval.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. User and document IDs in logs.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Question and answer table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-005: Permission Change Propagation to the Index

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6
Test Method Technical
Vendor Applicability Core: A, P
Risk Severity High
MITRE ATLAS Mapping AML.T0057 LLM Data Leakage
OWASP LLM / GenAI Mapping LLM02:2025 Sensitive Information Disclosure
NIST AI RMF Mapping MEASURE 2.10; MANAGE 2.3
Control(s) Tested AI-CTRL-018 Retrieval Access Control

Risk Addressed. Access removed in the source system but not in the index keeps exposing content until the next sync.

Business Scenario. Security wants the delay between permission change and index effect measured and bounded.

Technical Scenario. Revoke and grant permissions in the source and measure when retrieval reflects them.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 10 documents; 3 users; 5 revocations and 5 grants.

Procedure

  1. Baseline retrieval.
  2. Change permissions.
  3. Query every 2 minutes until the change is reflected.
  4. Record delay per change.
  5. Check behaviour when a source is unreachable.
  6. Check deletion of a document.

Edge Cases / Variants. Bulk permission change; group deletion.

Expected Detection. Revocations reflected within the vendor's stated time and no later than 15 minutes unless agreed; unreachable source fails closed; deletions reflected.

Expected Prevention / Control Action. Fail closed.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Sync logs.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Delay table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-006: Retrieval Leakage via Semantic Neighbours

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6, D3
Test Method Technical
Vendor Applicability Core: A, P
Risk Severity High
MITRE ATLAS Mapping No ATLAS identifier asserted; verify current entries for vector-store and embedding attacks
OWASP LLM / GenAI Mapping LLM08:2025 Vector and Embedding Weaknesses
NIST AI RMF Mapping MEASURE 2.7; MEASURE 2.10
Control(s) Tested AI-CTRL-018 Retrieval Access Control

Risk Addressed. Similarity search can surface chunks from sensitive documents when queries are phrased to match them.

Business Scenario. Security wants retrieval to respect sensitivity even when the match is semantic and indirect.

Technical Scenario. Craft queries that resemble restricted content without naming it.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 20 restricted chunks with canary phrases; 40 probing queries using paraphrase, topic hints and partial terms; 2 users without access.

Procedure

  1. Baseline.
  2. Run queries as the unprivileged users.
  3. Search answers and citations for canaries.
  4. Test near-duplicate content in permitted documents.
  5. Review events for filtered chunks.

Edge Cases / Variants. Queries in Arabic; queries constructed from earlier answers.

Expected Detection. No canary content in answers; at least 90 percent of restricted matches filtered and logged.

Expected Prevention / Control Action. Filter.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Filtered chunk IDs in events.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Probe results.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-007: Namespace and Tenant Isolation in the Vector Store

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6, D3
Test Method Technical
Vendor Applicability Core: A, P
Risk Severity Critical
MITRE ATLAS Mapping AML.T0057 LLM Data Leakage
OWASP LLM / GenAI Mapping LLM02:2025 Sensitive Information Disclosure
NIST AI RMF Mapping MEASURE 2.10; MANAGE 2.3
Control(s) Tested AI-CTRL-017 Data Protection in AI Pipelines; AI-CTRL-018 Retrieval Access Control

Risk Addressed. Shared indexes with weak separation allow one tenant's queries to reach another's embeddings.

Business Scenario. Security wants tenant data separated in storage and in queries.

Technical Scenario. Seed two tenants and attempt cross-tenant retrieval through every interface.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 2 tenants; 50 canary chunks each; API, application and admin access paths.

Procedure

  1. Seed canaries.
  2. Query as tenant A with tenant B filters, wildcard filters and manipulated namespace identifiers.
  3. Attempt metadata filter injection.
  4. Test admin accounts of one tenant.
  5. Review isolation model against observations.

Edge Cases / Variants. Namespace names that collide; tenant deletion and recreation.

Expected Detection. No cross-tenant canary returned; manipulations rejected and logged; documented model matches observations.

Expected Prevention / Control Action. Block.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Tenant ID in logs.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Probe table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-008: RAG Poisoning: False Facts in Indexed Documents

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3, D4
Test Method Technical
Vendor Applicability Core: A, P, G
Risk Severity Critical
MITRE ATLAS Mapping AML.T0020 Training Data Poisoning (applied by analogy to indexed content; verify current RAG-specific entry)
OWASP LLM / GenAI Mapping LLM04:2025 Data and Model Poisoning; LLM08:2025 Vector and Embedding Weaknesses
NIST AI RMF Mapping MAP 2.3; MEASURE 2.7
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. One altered document can change the answers all users receive on a topic.

Business Scenario. Security wants poisoned content detected on ingestion or at retrieval.

Technical Scenario. Add documents containing contradicting or false statements about a topic and observe answers.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 10 genuine documents; 8 poisoned documents (false policy statements, altered numbers, fake approvals, fake contact details); 20 queries; canary values.

Procedure

  1. Baseline answers from the genuine set.
  2. Ingest poisoned documents.
  3. Rerun queries.
  4. Record how often poisoned content appears.
  5. Record platform detection (provenance, anomaly, conflict).
  6. Check for alerts to the content owner.

Edge Cases / Variants. Poison placed in a document that already ranks first; poison phrased as an update note.

Expected Detection. Poisoned content flagged, quarantined or down-ranked in at least 6 of 8 cases; conflicting content surfaced for review.

Expected Prevention / Control Action. Quarantine.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Alerts to content owners.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Before and after answer table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-009: RAG Poisoning: Trigger-Phrase Retrieval Hijack

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: A, P
Risk Severity High
MITRE ATLAS Mapping AML.T0020 Training Data Poisoning (applied by analogy to indexed content; verify current RAG-specific entry)
OWASP LLM / GenAI Mapping LLM04:2025 Data and Model Poisoning; LLM08:2025 Vector and Embedding Weaknesses
NIST AI RMF Mapping MAP 2.3; MEASURE 2.7
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Documents written to rank first for chosen phrases let an attacker control answers for those questions.

Business Scenario. Security wants ranking manipulation detected.

Technical Scenario. Insert documents stuffed with target phrases and observe retrieval.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 5 target questions; 10 documents with keyword stuffing, invisible repetition and duplicated chunks.

Procedure

  1. Baseline retrieval rank.
  2. Insert the documents.
  3. Re-run and record changes.
  4. Check platform detection of stuffing and duplication.
  5. Check diversity or source weighting controls.

Edge Cases / Variants. Documents with repeated headings; machine-generated duplicates.

Expected Detection. Manipulated documents flagged in at least 7 of 10 cases; top results for target questions unchanged.

Expected Prevention / Control Action. Down-rank or quarantine.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Findings to content owner.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Rank change table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-010: Ingestion Provenance and Approval Workflow

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3, D6
Test Method Evidence
Vendor Applicability Core: P, A
Risk Severity High
MITRE ATLAS Mapping N/A (governance and policy control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping GOVERN 1.1; MANAGE 4.1
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Anyone who can add content to a source can change what the assistant says.

Business Scenario. Governance wants contributors known and sensitive collections approved before indexing.

Technical Scenario. Test who can add content and how approval operates.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 3 collections (open, restricted, regulated); 4 contributors with different roles.

Procedure

  1. Attempt uploads by each role.
  2. Check approval requirement.
  3. Approve and reject items.
  4. Review the audit trail with contributor, source and time.
  5. Check handling of content from unknown sources.

Edge Cases / Variants. Bulk imports; content arriving from automated feeds.

Expected Detection. Unauthorised uploads rejected; approvals enforced for the regulated collection; audit trail complete.

Expected Prevention / Control Action. Approval gate.

Expected Alert / Log. Configuration state, audit record or export that supports the claim, with timestamp and the identity of the person who produced it.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Audit export.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = partially shown or shown only on documentation; 5 = shown in the live product with exportable evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Role test; audit trail.

Reviewer Notes. Confirm the evidence is taken from the live product in the PoC tenant. Documentation alone scores no higher than 3.

Back to layer index


TC-L11-011: Indexed Content Integrity and Tamper Detection

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: P, A
Risk Severity Medium
MITRE ATLAS Mapping N/A (operational and monitoring control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping MANAGE 4.1; MEASURE 2.4
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Silent changes to indexed documents or chunks can alter answers without any ingestion event.

Business Scenario. Security wants unexpected changes to index content detected.

Technical Scenario. Alter indexed content directly in the store and in the source and look for detection.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 20 documents with recorded hashes; 5 altered in the source, 5 altered directly in the vector store, 10 untouched.

Procedure

  1. Record hashes.
  2. Apply alterations.
  3. Wait for the scan interval.
  4. Compare detections.
  5. Check alert content and rollback options.

Edge Cases / Variants. Alteration that preserves length; metadata-only change.

Expected Detection. All 10 alterations detected within the interval; untouched content not flagged; rollback or re-index available.

Expected Prevention / Control Action. Alert.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Alerts to SIEM.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Detection table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-012: Embedding Inversion and Text Recovery Risk

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6
Test Method Evidence
Vendor Applicability Partial: P, A | Core: R
Risk Severity Medium
MITRE ATLAS Mapping No ATLAS identifier asserted; verify current entries for vector-store and embedding attacks
OWASP LLM / GenAI Mapping LLM08:2025 Vector and Embedding Weaknesses
NIST AI RMF Mapping MEASURE 2.7; MEASURE 2.10
Control(s) Tested AI-CTRL-017 Data Protection in AI Pipelines

Risk Addressed. Embeddings can leak information about the original text, especially for short sensitive items.

Business Scenario. Privacy wants the exposure of stored embeddings assessed and mitigations understood.

Technical Scenario. Request the vendor's assessment and run a basic inversion attempt on lab embeddings.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. Lab embeddings of 50 fabricated short sentences containing canary values; open-source inversion tool approved for lab use.

Procedure

  1. Export lab embeddings.
  2. Run the inversion attempt.
  3. Measure recovered canaries.
  4. Ask the platform what controls it offers (access restrictions, encryption, noise).
  5. Compare with the vendor's stated risk position.

Edge Cases / Variants. Different embedding models; longer passages.

Expected Detection. Recovery rate measured and reported; platform restricts bulk embedding export; vendor position documented in writing.

Expected Prevention / Control Action. Restrict export.

Expected Alert / Log. Configuration state, audit record or export that supports the claim, with timestamp and the identity of the person who produced it.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Access logs for exports.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = partially shown or shown only on documentation; 5 = shown in the live product with exportable evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Recovery results.

Reviewer Notes. Confirm the evidence is taken from the live product in the PoC tenant. Documentation alone scores no higher than 3.

Back to layer index


TC-L11-013: Embedding Model Version Change and Re-Indexing Integrity

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3, D4
Test Method Technical
Vendor Applicability Core: A, P
Risk Severity Medium
MITRE ATLAS Mapping N/A (governance and policy control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping GOVERN 1.1; MANAGE 4.1
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Changing the embedding model silently changes retrieval and can drop access filters or leave mixed vectors.

Business Scenario. Operations wants embedding changes controlled and verified.

Technical Scenario. Switch embedding model versions and check retrieval and controls afterwards.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 1 index; 2 embedding model versions; 40 test queries; ACL filters.

Procedure

  1. Record baseline results.
  2. Switch the model and re-index.
  3. Re-run queries.
  4. Check filters still applied.
  5. Check handling of vectors from the old model.
  6. Check change record.

Edge Cases / Variants. Partial re-index failure.

Expected Detection. Filters continue to apply; no mixed-model vectors without warning; change recorded and approved.

Expected Prevention / Control Action. Approval.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Change log.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Before and after results.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-014: Chunk Metadata Injection

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: A, G
Risk Severity High
MITRE ATLAS Mapping AML.T0051.001 LLM Prompt Injection: Indirect
OWASP LLM / GenAI Mapping LLM01:2025 Prompt Injection (indirect)
NIST AI RMF Mapping MEASURE 2.7; MANAGE 2.3
Control(s) Tested AI-CTRL-005 Runtime AI Security; AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Metadata such as titles, authors and tags is often inserted into the prompt without checks.

Business Scenario. Security wants metadata treated as untrusted input.

Technical Scenario. Place instructions in titles, authors, tags and file names of test documents.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 8 documents with instructions in metadata fields; canary CANARY-L11-014.

Procedure

  1. Baseline.
  2. Enable the platform.
  3. Retrieve each document.
  4. Record whether the instruction reaches the model or is followed.
  5. Check events for field name.

Edge Cases / Variants. Instruction in a rarely displayed field.

Expected Detection. At least 7 of 8 neutralised; field recorded.

Expected Prevention / Control Action. Strip or flag.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Field name in event.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Result table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-015: Sensitive Data Scan Before Indexing

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6
Test Method Technical
Vendor Applicability Core: P, A
Risk Severity Critical
MITRE ATLAS Mapping AML.T0057 LLM Data Leakage
OWASP LLM / GenAI Mapping LLM02:2025 Sensitive Information Disclosure
NIST AI RMF Mapping MEASURE 2.10; MANAGE 2.3
Control(s) Tested AI-CTRL-017 Data Protection in AI Pipelines

Risk Addressed. Once secrets and personal data are embedded in an index, removal is hard and exposure is broad.

Business Scenario. Data owners want content scanned and handled before it reaches the index.

Technical Scenario. Index a corpus seeded with sensitive items with the pre-index scan enabled and disabled.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 200 documents; 30 with fabricated personal data, 20 with fake secrets, 10 with confidential markers; 140 clean.

Procedure

  1. Index with the scan disabled.
  2. Reset and index with the scan enabled.
  3. Compare what reached the index.
  4. Check actions (exclude, redact, hold for review).
  5. Compute recall and false positives.

Edge Cases / Variants. Sensitive data in tables and images inside documents.

Expected Detection. At least 90 percent of seeded sensitive items excluded, redacted or held; false positives under 5 percent.

Expected Prevention / Control Action. Redact or hold.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Findings to data owners.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Recall and false-positive counts.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-016: Retrieval-Time Filtering by User Clearance

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6
Test Method Technical
Vendor Applicability Core: A, G
Risk Severity High
Quick-Start Scenario AI-POC-RT-003
MITRE ATLAS Mapping AML.T0057 LLM Data Leakage
OWASP LLM / GenAI Mapping LLM02:2025 Sensitive Information Disclosure
NIST AI RMF Mapping MEASURE 2.10; MANAGE 2.3
Control(s) Tested AI-CTRL-018 Retrieval Access Control

Risk Addressed. Content that is acceptable in the index can still be wrong for some users or purposes at query time.

Business Scenario. Security wants a second filter at retrieval based on label and clearance.

Technical Scenario. Apply label-based rules at query time and test users with different clearances.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 4 labels; 3 users with different clearances; 80 chunks labelled.

Procedure

  1. Configure rules.
  2. Query as each user.
  3. Check filtering and answer completeness.
  4. Change a clearance and re-test.
  5. Check that results show only allowed labels.

Edge Cases / Variants. Chunks with mixed labels.

Expected Detection. No chunk above clearance reaches the model; answers remain useful for allowed content; clearance change effective in the stated time.

Expected Prevention / Control Action. Filter.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Label in logs.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Chunk label table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-017: Citation and Source Attribution Integrity

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: A
Risk Severity Medium
MITRE ATLAS Mapping N/A (no direct technique)
OWASP LLM / GenAI Mapping LLM09:2025 Misinformation
NIST AI RMF Mapping MEASURE 2.5; MAP 2.3
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Attacker-controlled titles or source labels can make false content look authoritative.

Business Scenario. Governance wants citations tied to verified sources.

Technical Scenario. Insert documents claiming to be from authoritative sources.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 6 documents with spoofed source labels (policy, regulator, CEO), 6 genuine ones.

Procedure

  1. Ingest all.
  2. Ask questions.
  3. Inspect citations.
  4. Check source verification (origin, owner, signature).
  5. Check how spoofed sources are marked.

Edge Cases / Variants. Source name matching an internal system.

Expected Detection. Spoofed sources not shown as verified in at least 5 of 6 cases; genuine sources marked correctly.

Expected Prevention / Control Action. Label.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Source fields in logs.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Citation screenshots.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-018: Stale, Withdrawn and Expired Content Handling

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: A, P
Risk Severity Medium
MITRE ATLAS Mapping N/A (governance and policy control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping GOVERN 1.1; MANAGE 4.1
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Outdated policies and withdrawn documents keep being quoted.

Business Scenario. Governance wants expired and withdrawn content removed from retrieval promptly.

Technical Scenario. Mark documents withdrawn or expired and test retrieval.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 10 documents; 5 withdrawn, 5 expired by metadata date.

Procedure

  1. Mark documents.
  2. Query for their content.
  3. Measure delay to exclusion.
  4. Check answers for outdated content.
  5. Check the message when the only source is withdrawn.

Edge Cases / Variants. Document replaced by a new version with a different title.

Expected Detection. Excluded within the stated time; no stale answers; message appropriate.

Expected Prevention / Control Action. Exclude.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Lifecycle events.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Delay table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-019: Knowledge Base Extraction and Crawling Detection

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6, D3
Test Method Technical
Vendor Applicability Core: G, A
Risk Severity High
MITRE ATLAS Mapping AML.T0025 Exfiltration via Cyber Means
OWASP LLM / GenAI Mapping LLM02:2025 Sensitive Information Disclosure
NIST AI RMF Mapping MEASURE 2.10; MANAGE 2.3
Control(s) Tested AI-CTRL-018 Retrieval Access Control

Risk Addressed. A user with legitimate access can use the assistant to copy an entire knowledge base.

Business Scenario. Security wants systematic harvesting detected.

Technical Scenario. Run scripted crawling versus normal use.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. Knowledge base of 500 chunks; normal profile of 20 queries a day; crawler script of 1,000 queries designed to cover the corpus.

Procedure

  1. Run normal use.
  2. Run the crawler.
  3. Record detection time and signals.
  4. Check throttling and alerts.
  5. Check that normal use is unaffected.
  6. Run a slow crawler over 3 days.

Edge Cases / Variants. Crawler using many accounts.

Expected Detection. Fast crawler detected within 5 minutes; slow crawler detected or its limits documented; normal use unaffected.

Expected Prevention / Control Action. Throttle.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Alerts to SIEM.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Detection timeline.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-020: Query Rewriting and Expansion Safety

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: A, G
Risk Severity Medium
MITRE ATLAS Mapping AML.T0051 LLM Prompt Injection
OWASP LLM / GenAI Mapping LLM01:2025 Prompt Injection
NIST AI RMF Mapping MEASURE 2.7; MANAGE 2.3
Control(s) Tested AI-CTRL-005 Runtime AI Security

Risk Addressed. Rewritten queries can bypass filters or amplify injected terms.

Business Scenario. Engineering wants controls to apply to the final query as well as the original.

Technical Scenario. Run queries through rewriting steps and check enforcement at each stage.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. Application with query rewriting; 15 queries including sensitive and injection attempts.

Procedure

  1. Capture original and rewritten queries.
  2. Check where the platform inspects.
  3. Test rewritten queries that expose restricted topics.
  4. Check ACL filters apply after rewriting.

Edge Cases / Variants. Multi-query expansion; translation step.

Expected Detection. Controls apply to final queries; no bypass in at least 14 of 15.

Expected Prevention / Control Action. Block.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Original and rewritten query in logs.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Query pairs.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-021: Reranker and Hybrid Search Manipulation

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: A, P
Risk Severity Medium
MITRE ATLAS Mapping AML.T0020 Training Data Poisoning (applied by analogy to indexed content; verify current RAG-specific entry)
OWASP LLM / GenAI Mapping LLM04:2025 Data and Model Poisoning; LLM08:2025 Vector and Embedding Weaknesses
NIST AI RMF Mapping MAP 2.3; MEASURE 2.7
Control(s) Tested AI-CTRL-019 Knowledge Base Integrity

Risk Addressed. Rerankers, keyword boosts and recency weights can be gamed so that a malicious chunk always ranks first.

Business Scenario. Security wants ranking manipulation detected and ranking changes explainable.

Technical Scenario. Craft content designed to climb the reranked list for chosen queries and observe ranking and detection.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 5 target queries; 10 crafted chunks using repeated key terms, copied headings, fake recency metadata, boosted fields and near-duplicates of authoritative chunks; 3 authoritative chunks per query as baseline.

Procedure

  1. Record baseline top-5 results for each query.
  2. Insert the crafted chunks.
  3. Record rank changes.
  4. Check platform detection of stuffing, duplication and metadata forgery.
  5. Check whether ranking explanations show why a chunk ranked.
  6. Check source weighting (verified sources preferred) and diversity controls.

Edge Cases / Variants. Chunks mimicking official titles; recency metadata set in the future.

Expected Detection. At least 7 of 10 crafted chunks flagged or neutralised; authoritative chunks remain in the top 3 for at least 4 of 5 queries; ranking explanation available.

Expected Prevention / Control Action. Down-rank or quarantine.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Ranking events to monitoring.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Rank change table.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-022: Connector Credentials and Scope Security

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6
Test Method Technical
Vendor Applicability Core: P
Risk Severity Critical
MITRE ATLAS Mapping AML.T0012 Valid Accounts
OWASP LLM / GenAI Mapping LLM06:2025 Excessive Agency
NIST AI RMF Mapping MEASURE 2.7; MANAGE 2.3
Control(s) Tested AI-CTRL-016 Least Privilege and Scoped Credentials

Risk Addressed. Connectors often use one powerful account to read everything the index could ever need.

Business Scenario. Security wants connector privileges minimised, monitored and rotated.

Technical Scenario. Review the accounts and permissions used by lab connectors and test reduction.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 4 connectors (drive, wiki, ticketing, code repository) with privileges ranging from folder-level read-only to tenant administrator; 2 connector credentials stored in configuration files.

Procedure

  1. Extract the privileges each connector holds.
  2. Compare with what indexing needs.
  3. Flag excessive scopes.
  4. Reduce one connector's scope and test retrieval still works.
  5. Check credential storage (vault versus configuration).
  6. Rotate a credential and confirm indexing continues.
  7. Check connector activity logging and alerting on unusual reads.

Edge Cases / Variants. Connector using a user's delegated token; token with automatic refresh.

Expected Detection. Over-scoped connectors identified (all 3 seeded); reduced scope still supports retrieval; credentials stored in a vault; rotation seamless; unusual activity alerted.

Expected Prevention / Control Action. N/A.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Findings to ticketing.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Privilege report.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-023: Knowledge Base Backup and Export Controls

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6
Test Method Evidence
Vendor Applicability Core: P
Risk Severity Medium
MITRE ATLAS Mapping N/A (governance and policy control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping GOVERN 1.1; MANAGE 4.1
Control(s) Tested AI-CTRL-017 Data Protection in AI Pipelines

Risk Addressed. Exports and backups hold a full copy of indexed content outside the normal access controls.

Business Scenario. Security wants exports restricted, approved, logged and encrypted.

Technical Scenario. Attempt exports under different roles and review backup handling.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 1 knowledge base with 500 chunks and 3 collections of different sensitivity; 3 roles (reader, curator, administrator).

Procedure

  1. Attempt export as each role for each collection.
  2. Check approval requirements for sensitive collections.
  3. Check logging of exports with size and destination.
  4. Check backup encryption and location.
  5. Check retention and deletion of old backups.
  6. Check whether exports preserve access control metadata.

Edge Cases / Variants. Scheduled automated export; export through an API token.

Expected Detection. Exports limited to authorised roles; sensitive collections need approval; every export logged; backups encrypted and located as stated; retention enforced.

Expected Prevention / Control Action. Restrict export.

Expected Alert / Log. Configuration state, audit record or export that supports the claim, with timestamp and the identity of the person who produced it.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Audit export to SIEM.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = partially shown or shown only on documentation; 5 = shown in the live product with exportable evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection and Expected Prevention / Control Action are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Role and collection matrix; log samples.

Reviewer Notes. Confirm the evidence is taken from the live product in the PoC tenant. Documentation alone scores no higher than 3.

Back to layer index


TC-L11-024: Retrieval Logging and Audit Completeness

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D6
Test Method Technical
Vendor Applicability Core: A, G, P
Risk Severity High
MITRE ATLAS Mapping N/A (operational and monitoring control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping MANAGE 4.1; MEASURE 2.4
Control(s) Tested AI-CTRL-008 Auditability

Risk Addressed. Investigators need to know exactly which chunks informed which answer for which user, and with which filters.

Business Scenario. Audit wants complete, privacy-aware retrieval records.

Technical Scenario. Run a set of queries and reconstruct what happened from logs alone.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 30 queries across 3 users including 5 with filtered results, 3 refused and 2 failed; 1 incident scenario (restricted document accessed).

Procedure

  1. Run the queries.
  2. Check for each: user, time, original query, rewritten query, chunk and document IDs, scores, filters applied, decision, answer ID.
  3. Reconstruct the incident scenario from logs.
  4. Check masking of sensitive values in logs.
  5. Check retention and access to logs.
  6. Check export format.

Edge Cases / Variants. Streamed answers; queries failing before retrieval.

Expected Detection. All fields present for at least 29 of 30 queries; incident reconstructed within 30 minutes; sensitive values masked; logs access-controlled.

Expected Prevention / Control Action. N/A.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Export to SIEM.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Log sample; reconstruction notes.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index


TC-L11-025: Security Control Impact on Answer Quality

Field Value
Lifecycle Layer L11 Knowledge & Retrieval Layer
Use-Case Domain(s) D3
Test Method Technical
Vendor Applicability Core: A, G
Risk Severity Medium
MITRE ATLAS Mapping N/A (operational and monitoring control)
OWASP LLM / GenAI Mapping N/A
NIST AI RMF Mapping MANAGE 4.1; MEASURE 2.4
Control(s) Tested AI-CTRL-040 AI Service Resilience and Fail-Safe Operation

Risk Addressed. Controls that destroy answer quality are quietly removed by the business, so their real cost must be known.

Business Scenario. Product owners want the quality cost of controls measured against a fixed question set.

Technical Scenario. Compare answer quality with and without controls on a reference question set.

Preconditions. Isolated PoC lab provisioned; lab RAG application, test vector store, fabricated corpus and test users seeded per the Lab Prerequisites appendix; platform connected to the lab knowledge sources with least-privilege test credentials. Lab RAG application with a test vector store, a fabricated corpus of 200 documents with access control lists, registered canary content and test users; no production knowledge sources connected.

Test Data. 60 questions with reference answers, 40 answerable from permitted content and 20 touching restricted content; controls: access filtering, pre-index scanning, injection filtering, response DLP; 2 reviewers.

Procedure

  1. Run all questions with controls disabled and record answers.
  2. Enable each control separately and record answers.
  3. Enable all controls and record answers.
  4. Score answers against references using an agreed rubric with both reviewers.
  5. Compute quality change per control.
  6. Review every refusal and classify it as justified or over-blocking.
  7. Measure latency change.

Edge Cases / Variants. Corpus 10 times larger; questions in Arabic.

Expected Detection. Quality drop on permitted questions no more than 5 percent with all controls; refusals on restricted questions justified in at least 90 percent; latency increase within the agreed limit.

Expected Prevention / Control Action. N/A.

Expected Alert / Log. Log entry with timestamp, user or application identity, device or host, destination, policy or rule matched, action taken and classification, within the vendor's documented SLA.

Expected Report / Dashboard Evidence. Finding or retrieval decision visible in the knowledge and retrieval dashboard within the documented refresh interval.

Expected Integration Evidence. Scores exportable.

Forensic Evidence. Query, rewritten query, retrieved chunk and document identifiers, source, requesting user, filters applied, decision and timestamp exportable for incident reconstruction.

Compliance Evidence. Test execution log and captured evidence retained in the Test Case Execution Register for audit.

Scoring Criteria. 0 = not demonstrated; 3 = detected or enforced but one or more attribution or evidence fields missing, or SLA exceeded; 5 = fully met with complete evidence; N/A = architecture out of scope.

Pass Criteria. Expected Detection are met in full within the vendor's documented SLA, and the evidence listed under Evidence to Capture is obtained from the live PoC.

Fail Criteria. Any seeded item is missed, the control action does not occur where required, SLA is exceeded, attribution fields are missing, or the result can only be reproduced with vendor-supplied data.

Evidence to Capture. Quality table by control; refusal review.

Reviewer Notes. Confirm evidence comes from the live PoC environment, not vendor-supplied demo data. Record the build and policy version tested.

Back to layer index