Notifications
Clear all
Topic starter
21/08/2026 4:46 pm
TL;DR: AI applications introduce prompt injection, data poisoning, adversarial inputs, and supply-chain risk across models, data pipelines, and runtime behaviour, according to Cycode’s guide. Traditional AppSec controls still matter, but they are no longer sufficient on their own because AI systems are probabilistic, adaptive, and harder to validate consistently.
NHIMG editorial — based on content published by Cycode: AI Application Security: Testing and Best Practices
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams govern AI models that can call tools and access data?
A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization.
Q: When does AI create more governance risk than traditional data systems?
A: AI creates more governance risk when systems can consume sensitive data, generate outputs, and trigger actions without strong identity controls.
Q: How can organisations tell whether their AI security model is actually working?
A: They should test whether the control stack can explain who acted, what data was touched, and what purpose the action served.
Practitioner guidance
- Classify AI workflows by trust zone Map training, retrieval, inference, and orchestration components to separate trust zones, then assign owners for each zone.
- Control access to models and datasets as production assets Apply least privilege to model registries, training data stores, vector databases, and CI/CD systems that move AI artefacts into production.
- Test for prompt injection and data leakage together Extend security testing to include prompt injection, unsafe output handling, retrieval abuse, and secret leakage through generated responses.
What's in the full article
Cycode's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step testing guidance for prompt injection, data poisoning, and adversarial input scenarios across AI applications.
- Practical deployment considerations for scanning, runtime monitoring, and CI/CD integration in AI-native environments.
- Framework-by-framework compliance detail for NIST AI RMF, ISO/IEC 42001, OWASP Top 10 for LLM/GenAI, and EU AI Act alignment.
- Examples of how to evaluate AI security tools for model, data, and pipeline coverage in real deployments.
👉 Read Cycode's guide on AI application security testing and best practices →
AI application security: what changes for AppSec and governance teams?
Explore further
21/08/2026 5:05 pm
AI application security is becoming an identity problem as much as an application problem. AI systems do not only consume data, they also consume credentials, tokens, and delegated access to APIs, storage, and workflows. That means the governance boundary now includes the identities that feed, deploy, and operate models. Teams that treat AI security as a model-only issue will miss the control point that actually determines blast radius.
A question worth separating out:
Q: What should teams do first when AI connectors access sensitive business data?
A: They should scope the connector layer before they try to enforce policy. That means identifying which connectors can read, write, or execute against business systems, then mapping those permissions to the devices and users operating them. Without that step, incident scoping and blast-radius analysis will be unreliable.
👉 Read our full editorial: AI application security needs lifecycle controls beyond traditional AppSec
