Hey folks, been working through our ISO 27001 recertification and hit A.14.2.1 (Security in development and support processes). Our auditors are really zooming in on our agent runtimes, specifically how we handle prompt injection for our internal support bots.

The big question: what's the most effective way to **document** these defenses to satisfy the audit requirement for secure development practices? They don't just want a verbal "we have filters," they want to see it in the process.

Here's what we ended up presenting, which got a thumbs-up:

* **Process Documentation:** A clear step in our SDLC flowchart for "LLM Interaction Security Review." This mandates a threat model for any feature using prompts, with prompt injection called out explicitly.
* **Technical Controls Log:** A living document (we use a wiki) that lists each agent runtime and its specific mitigations. For example:
```
Agent: Deployment Validator Bot
Purpose: Checks Docker compose files for security issues.
Mitigations:
1. Input Sandboxing: All user input is placed into a dedicated, non-executable context field.
2. Instructional Guardrails: System prompt includes strict command separation using XML tags.
3. Output Validation: Regex parsing on the agent's output to allow only a whitelist of commands.
4. Logging: All prompts and completions are logged to our SIEM for anomaly detection.
```
* **Evidence:** We linked to actual test cases in our QA suite that simulate injection attempts (e.g., "Ignore previous instructions...") and show the blocked/logged result.

The common gap they flagged initially was having these controls but not showing a formal **review and update cycle**. We now have a quarterly task to review new injection techniques and update our guardrails and test cases.

What are you all using? Especially interested in how you handle documentation for dynamic, non-deterministic systems.