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.
Editorial analysis by NHI Mgmt Group, based on content published by Protect AI: “Security Spotlight: AppSec to AI, a Security Engineer's Journey”.
Key questions
Q: How should security teams extend AppSec controls to AI systems?
A: Security teams should keep input validation, authentication, and least privilege, but extend them to prompts, model access, training data, and runtime monitoring.
Q: Why do traditional application controls miss the biggest AI security risks?
A: Traditional controls focus on code, dependencies, and perimeter testing, while AI risk also includes model poisoning, prompt injection, training data leakage, and output abuse.
Q: What are the signs that AI penetration testing is not giving enough coverage?
A: Coverage is likely too narrow when testing only runs on snapshots, checks a limited set of endpoints, or fails to adapt after an error or unexpected response.
Practitioner guidance
- Define AI security requirements separately from AppSec requirements Map prompt handling, model access, training data protection, and runtime monitoring into their own control set so they are not diluted inside generic application security standards.
- Inventory models, prompts, and training data as governed assets Track model versions, approved data sources, fine-tuning artefacts, and known limitations so security teams can answer what is deployed and what influenced it.
- Add AI-specific testing to your assurance workflow Use model scanning, automated red teaming, and runtime abuse testing alongside SAST, SCA, and DAST to cover attack paths that traditional tooling misses.
Bottom line: Traditional AppSec remains relevant for AI systems, but it does not cover the full control surface once prompts, models, and training data become part of the risk model.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 11:13 pm
AppSec principles still apply, but they no longer define the boundary of control. AI systems inherit input validation, authentication, and least privilege, yet the protected object is no longer just code and data. Models can be manipulated through prompts, training data, and output channels, so the control plane expands beyond the application perimeter. The practitioner conclusion is simple: AI security is AppSec plus model and data governance, not AppSec renamed.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: What is the difference between AppSec and AI security governance?
A: AppSec secures software applications through code, runtime, and infrastructure controls. AI security governance adds oversight of model provenance, training data, behavioural limits, and post-deployment monitoring. The difference is that AI can be influenced by data and prompts after deployment, so governance must follow the model throughout its lifecycle.
👉 Read our full editorial: AppSec-to-AI security needs new controls for AI systems
This post was modified 2 days ago by NHI Mgmt Group