HR Assistant Prompt Injection, Over-Broad Retrieval, and EU Data
A 4,000-employee company deploys an HR assistant that retrieves from a single embedding index covering every internal wiki space, including documents uploaded by external vendors. The assistant can call two tools: an internal email API and a ticketing API. During red-teaming, an injected instruction hidden in a vendor onboarding PDF caused the assistant to attempt to email a salary table to an external address; the egress filter blocked it. Logs are kept for 30 days in a US region. About 1,100 employees are in the EU and are subject to GDPR. The LLM provider retains prompts for 30 days for abuse monitoring and processes them in the US. Wiki access is enforced by space-level permissions, but the assistant's index does not carry those permissions and retrieves across all spaces. The security team wants a remediation plan before the assistant expands to finance documents next quarter.
1. Identify the highest-risk gaps and the control you would implement first.
Read the worked answer
The highest-risk gaps are indirect prompt injection through untrusted documents, over-broad retrieval that ignores document permissions, and tool access that can send data externally. The injection succeeded because retrieved content is treated as instructions, and the blast radius was limited only by an egress filter.
I would implement permission-aware retrieval first. Security trimming at query time - filtering the index by the requesting user's entitlements before any chunk is returned - addresses the largest data-leakage path and reduces what an injected document can reach. It also fixes the current situation where any employee can surface content from spaces they cannot open.
Immediately after that: treat all retrieved text as untrusted data, delimit it, and instruct the model never to follow instructions found in documents; restrict the email tool to internal recipients with a human confirmation step; and keep egress filtering with logging. The first control is prioritized because it limits both accidental and adversarial disclosure regardless of what the model does.
2. Design the retrieval and tool-use architecture with least privilege.
Read the worked answer
Retrieval should carry identity end to end. The assistant authenticates the user, resolves group and space memberships, and applies an ACL filter in the vector store so only permitted chunks are candidates. Sensitive spaces such as HR investigations or finance should sit in separate indexes with separate service identities, not one shared index.
Tools should be allowlisted, typed, and narrow. The email tool should accept an internal recipient from a validated directory, not free-form addresses; external recipients should be blocked or require explicit human approval. The ticketing tool should be scoped to the user's own tickets or team queue. Every tool call should be logged with the user, parameters, retrieved chunk IDs, and outcome.
Retrieved content should be inserted in a clearly delimited data block, with system instructions that override document content and prohibit tool calls based on document instructions. Add output DLP scanning, rate limits, canary tokens to detect exfiltration attempts, and a confirmation prompt for any action with side effects. Credentials should never be placed in the prompt or reachable by the model.
3. Address the logging, retention, and EU data residency issues in the remediation plan.
Read the worked answer
Thirty days of logs in the US is inadequate for investigating an injection incident, supporting legal hold, or demonstrating GDPR accountability. I would extend retention to at least 12 months for security and audit events, with minimization: store hashes or redacted prompts where full text is not needed, restrict access, and set a documented deletion schedule. EU employee data and EU logs should be stored in an EU region.
The provider's 30-day abuse-monitoring retention and US processing need a contractual fix: a data processing agreement with appropriate transfer mechanisms, a zero-retention or EU-region endpoint, and pseudonymization before sending prompts. The company should complete a DPIA covering the assistant, define the lawful basis, and document how data subject access and deletion requests are handled across logs, indexes, and provider systems.
Operationally, I would add an incident-response playbook for prompt injection and data exposure, with detection alerts on anomalous tool calls and egress attempts, and I would not expand to finance documents until ACL enforcement, EU residency, and the retention changes are verified in testing.