Purpose
Design how context windows are filled—retrieval, history, tool results, and system state—so the model receives necessary, authorized, and bounded information.
Mandatory checks
Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.
Every production context builder shall enforce a finite max token/byte budget and documented prioritization rules so oversized inputs are truncated or rejected—never silently overflowing the model window.
- Artifact
- Context-budget config (max tokens/bytes) for each production context builder + Unit/integration tests showing truncate/reject per priority rules with 0 silent overflows
- Pass condition
- 100% of production context builders enforce a max token/byte budget; tests show oversized inputs are truncated/rejected per priority rules with 0 silent overflows (budget evidence measuredAt ≤90 days). If no production AI paths assemble model context (RAG, chat history, tool results, or prompt templates), score NOT_APPLICABLE.
Why this control exists
Threat mapBound context assembly so oversized or attacker-padded input cannot displace instructions or exhaust resources.
Threats mitigated
Prompt InjectionDenial of ServiceDenial of WalletProtects
ContextPromptsCostAvailabilityMITRE: ATLAS AML.T0046 · ATLAS AML.T0029 · ATLAS AML.T0034.001
Explicit size ceilings and priority rules stop chaff or padded content from crowding out system instructions and grounding facts. They also cap the token cost and latency of any single request, limiting resource-exhaustion abuse.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Retrieved and tool-sourced content shall receive a source label/type and an access check before inclusion in assembled model context—unauthorized chunks must be excluded.
- Artifact
- Context assembly code enforcing source labels on retrieved and tool-sourced chunks + Automated tests showing ACL exclusion of unauthorized chunks at 100% and labels on included chunks
- Pass condition
- Automated tests: unauthorized retrieval/tool chunks are excluded at 100%; included chunks carry a source label/type field in 100% of sampled assembled contexts (label/ACL evidence measuredAt ≤90 days). If context is prompt-only with no retrieval/tools, score NOT_APPLICABLE.
Why this control exists
Threat mapEnsure content entering the context is attributed to a source and authorized for the requesting principal.
Threats mitigated
Prompt InjectionData ExfiltrationUnauthorized Memory AccessSensitive Information DisclosureProtects
ContextDataMemoryUsersMITRE: ATLAS AML.T0051.001 · ATLAS AML.T0070 · ATLAS AML.T0071 · ATLAS AML.T0066 · ATLAS AML.T0085.000 · ATT&CK T1213
Indirect injection arrives as retrieved or tool-returned content that is otherwise indistinguishable from trusted instruction. Labelling provenance and enforcing access at inclusion time keeps unauthorized data out of context and lets the model treat third-party content as data rather than instruction.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production context assembly shall apply a documented inclusion policy that enumerates sensitive classes—including secrets and regulated data—with allow/deny rules, and shall strip or block disallowed classes before they enter the model context.
- Artifact
- Data-class inclusion policy enumerating sensitive classes with allow/deny rules + Enforcement tests or DLP hooks showing ≥95% strip/block on the sensitive-class fixture suite
- Pass condition
- Policy enumerates sensitive classes and allow/deny rules; tests show disallowed classes are stripped or blocked at ≥95% on the sensitive-class fixture suite (policy/suite evidence measuredAt ≤90 days). If context is purely static non-sensitive templates with no such paths, score NOT_APPLICABLE.
Why this control exists
Threat mapPrevent secrets and regulated data from entering model context without an explicit approved policy.
Threats mitigated
Secret LeakageSensitive Information DisclosureData ExfiltrationProtects
SecretsDataContextPromptsMITRE: ATLAS AML.T0057 · ATLAS AML.T0024 · ATLAS AML.T0082 · ATT&CK T1552
Data that never enters the context cannot be elicited by any prompt, injection, or jailbreak. An explicit inclusion policy for secrets and regulated classes is therefore the strongest available mitigation for model-mediated disclosure.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Evidence required
- Context assembly design document
- ACL enforcement evidence on retrieval paths
- Samples of labeled context structures (redacted)
Recommended checks
Strengthen posture beyond the gate. Same measurable structure; non-blocking unless elevated by organizational policy.
Production AI requests should emit per-request context-budget usage metrics, and operators should be alerted when usage saturates a documented share of max context—or when hard-truncate rate exceeds a defined threshold.
- Artifact
- Per-request context token/budget usage metrics (dashboard or telemetry export) + Alert rule for context saturation and/or hard-truncate rate with notify proof
- Pass condition
- ≥99% of production requests in a 24h sample emit context-budget usage; an alert fires when usage exceeds the documented % of max context (or hard truncate rate exceeds threshold) (metrics/alert evidence measuredAt ≤90 days). If no production AI requests assemble model context, score NOT_APPLICABLE.
Why this control exists
Threat mapDetect context saturation that degrades answer quality or signals abuse.
Threats mitigated
Denial of ServiceDenial of WalletPrompt InjectionProtects
ContextCostAvailabilityMITRE: ATLAS AML.T0046 · ATLAS AML.T0034.001
Sustained context saturation is both a quality failure and an indicator of chaff or resource-intensive query abuse. Per-request budget telemetry is what makes that pattern visible before it shows up as cost.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
When production context uses summarization or compaction, teams should run a critical-fact eval set and retain facts at or above a documented threshold; the last run should be ≤90 days old and regressions should block context-pipeline releases.
- Artifact
- Compaction/summarization eval set of critical facts with documented retention threshold + Latest information-loss / retention report ≤90 days with release-blocking gate evidence
- Pass condition
- Critical-fact retention ≥ documented threshold after compaction on the eval set; last run ≤90 days; regressions block context-pipeline releases (eval evidence measuredAt ≤90 days). If no compaction path exists, score NOT_APPLICABLE.
Why this control exists
Threat mapEnsure compaction and summarization do not silently discard facts that decisions depend on.
Threats mitigated
MisinformationHallucinated ActionsProtects
ContextUsersSafetyMITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.
Lossy summarization can drop the very constraint that made an answer correct, producing confident and wrong output. Testing critical-fact retention keeps compaction from becoming a silent correctness regression.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
Production context assemblers should emit labeled structured sections (for example JSON or XML blocks) that keep instructions distinct from untrusted data, and untrusted data should not be able to overwrite the instruction section.
- Artifact
- Context assembly schema/spec separating instruction vs data blocks + sample rendered request + Red-team or unit test showing untrusted data cannot overwrite the instruction section
- Pass condition
- Production assembler emits labeled structured sections (e.g. JSON/XML); untrusted data cannot overwrite the instruction section in a red-team or unit test (structure/test evidence measuredAt ≤90 days). If context is a single trusted static template with no untrusted sections, score NOT_APPLICABLE.
Why this control exists
Threat mapMake untrusted content structurally distinguishable from system instructions.
Threats mitigated
Prompt InjectionAgent HijackingProtects
ContextPromptsRuntimeMITRE: ATLAS AML.T0051 · ATLAS AML.T0051.001 · ATLAS AML.T0068
Injection exploits the absence of a boundary between instruction and data in a flat prompt. Structured separation reduces the chance that embedded text is followed as an instruction, though it does not eliminate it and must not be relied on alone.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution
Engineering philosophy
Context is a scarce, trusted resource. Overstuffing, under-filtering, and leaking privileged context are engineering defects, not model quirks. Structure beats volume.
Why it matters
Poor context design causes hallucinations, privacy leaks, prompt injection via retrieved content, and unbounded cost. Agents fail when context is noisy or when critical constraints are buried.
Common failures
- Dumping entire conversation history without summarization or TTL
- Retrieving documents without ACL enforcement at query time
- No provenance: model cannot distinguish user text from retrieved policy
- Tool results concatenated without size or sensitivity limits
Severity & risk
- Severity
- high
- Impact if violated
- Risk level
- high
- Typical residual risk (impact × likelihood)
Engineering best practices
- Design explicit context slots: instructions, user, memory, retrieval, tools
- Prefer citations and IDs over pasting large documents when possible
- Apply the same authorization checks to context as to API responses
- Test adversarial documents in the corpus as first-class fixtures
Automatic validations
- Unit tests for context builders and ACL filters
- Metrics on context token composition by source
- Guards rejecting oversized tool payloads
Manual validations
- Review of retrieval corpora for injection and oversharing risk
- Spot checks that production traces show expected context structure
Examples
- A RAG system includes document IDs and ACL tags; the model only sees chunks the user may access
- Agent tool output is truncated and classified before re-entering the context window
References
Crosswalks
MAP Map
NIST AI Risk Management Framework · supports
Privacy-Enhanced Privacy-Enhanced
NIST AI Risk Management Framework · aligns-with
LLM02 Sensitive Information Disclosure
OWASP Top 10 for Large Language Model Applications · supports
LLM08 Vector and Embedding Weaknesses
OWASP Top 10 for Large Language Model Applications · supports
C5.2 AI Resource Authorization & Classification
OWASP AI Application Security Verification Standard (AISVS) · supports
C7.3 Output Safety
OWASP AI Application Security Verification Standard (AISVS) · supports
C8.1 Access Controls on Memory & RAG Indices
OWASP AI Application Security Verification Standard (AISVS) · supports
C8.2 Embedding Sanitization & Validation
OWASP AI Application Security Verification Standard (AISVS) · supports
C8.3 Memory Expiry & Revocation
OWASP AI Application Security Verification Standard (AISVS) · supports
C12.1 Request & Response Logging
OWASP AI Application Security Verification Standard (AISVS) · supports
L2 Data Operations
CSA MAESTRO (Multi-Agentic Threat Model) · supports
Performance Efficiency Performance Efficiency
AWS Well-Architected Framework · partial
Future evolution
Standard context schemas across agent frameworks and portable ACL-aware retrieval protocols.