A housing-authority caseworker assistant concatenates untrusted resident email text directly into the model context. What injection-enabling flaw should the red team flag?

Concatenating untrusted resident email text directly into a housing-authority caseworker assistant's model context creates unsafe context assembly: untrusted content shares privileged context with system instructions and tools, enabling indirect prompt injection. The red team should flag the architectural flaw—mixing untrusted input into the same instruction window as authoritative policy—because that design is what makes injection practical. Correct remediation separates untrusted content, labels it as data not instructions, and applies sanitization or mediation before model consumption. Insecure log retention that stores prior caseworker chat transcripts in plaintext archives describes a data-at-rest exposure concern, a different flaw than how untrusted email content gets assembled into context in the first place. Weak access controls that allow residents to view other households case files address an authorization/data-separation concern, not the software-level context-assembly flaw that lets untrusted text share privileged context. Excessive tool privileges that let the assistant write to benefits payment systems are an authorization/over-privilege concern and don't explain how injection becomes possible when raw email text is concatenated into the prompt. Exam caveat: 'unsafe context assembly' is the enabling condition; the finding is about how content is composed for the model, not merely that email exists in the case file. Operational check: inspect the prompt template for raw email concatenation, introduce explicit delimiters and untrusted-content tags, deny tool calls driven solely by email-derived instructions, and retest with benign-looking emails that embed override attempts in the housing workflow.