Notifications
Clear all
Topic starter
12/06/2026 9:16 pm
TL;DR: Traditional AppSec principles still matter in AI security, but prompt injection, model poisoning, training data exposure, and runtime observability require controls beyond code scanning and perimeter testing, according to Protect AI. The security boundary shifts from applications alone to model, data, and governance layers that existing programmes often do not cover.
NHIMG editorial — based on content published by Protect AI: Security Spotlight, AppSec to AI, a security engineer's journey
Questions worth separating out
Q: How should security teams govern AI systems that can access sensitive data?
A: Security teams should treat AI systems as governed access paths, not just applications.
Q: Why do traditional AppSec controls fall short for AI applications?
A: Traditional AppSec controls fall short because they focus on code integrity and request validation, while AI systems also need controls for model behaviour, training data lineage, and output safety.
Q: What do security teams get wrong about prompt injection?
A: Teams often treat prompt injection as a text filtering issue, but it is really a boundary-crossing issue.
Practitioner guidance
- Define AI-specific access boundaries Map which users, service accounts, and pipelines can influence prompts, training data, retrieval sources, and model outputs.
- Add prompt abuse detections Instrument logging for prompt injection attempts, jailbreak patterns, and instruction-overriding content, then route those signals into the same triage process used for other high-risk security events.
- Inventory models and training data Track each model, version, fine-tuning source, and retrieval dependency with an owner and review date so you can prove what the system was exposed to and who approved it.
What's in the full article
Protect AI's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of AI-specific security testing methods, including model scanning and automated red teaming.
- A fuller explanation of the secure AI development lifecycle, including validation checkpoints and monitoring practices.
- The article's recommended way to combine traditional AppSec controls with AI-specific governance and observability.
- Practical guidance from the author's engineering perspective on building AI security skills inside a product security team.
👉 Read Protect AI's security engineer perspective on AppSec to AI security →
AppSec to AI security: are your controls keeping up?
Explore further
12/06/2026 11:13 pm
AppSec is necessary for AI security, but it is not sufficient. The article is right that familiar controls still matter, especially validation, authorization, and supply chain review. But AI systems add a behavioural layer that traditional AppSec was never designed to govern, because the model can reinterpret input rather than merely process it. The implication is that teams should stop treating AI as a normal application with a different interface and start treating it as a governed decision surface.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing how quickly new AI toolchains create identity exposure paths.
A question worth separating out:
Q: How can organisations know whether AI monitoring is actually working?
A: AI monitoring is working when it detects abuse patterns before they become harmful outputs or data leakage events. Useful signals include prompt-injection attempts, jailbreaks, sensitive data disclosure, and anomalous tool use. If the programme only reports uptime or request volume, it is measuring activity, not security.
👉 Read our full editorial: AppSec-to-AI security needs new controls for AI systems
