Topic starter
21/08/2026 5:00 pm
TL;DR: Traditional AppSec still covers the code around AI applications, but it misses prompts, models, agents, and runtime tool use, according to AccuKnox. Once an LLM becomes a live system that can read data or trigger actions, AI-native inventory, guardrails, and least-privilege controls become operationally necessary.
Editorial analysis by NHI Mgmt Group, based on content published by AccuKnox: “AI Security Tools vs AppSec Tools: Key Differences”.
Key questions
Q: What breaks when AI security is limited to AppSec scanning?
A: Static scanning misses emergent behaviour, so the organisation can approve code that later behaves outside policy in production.
Q: Why do AI agents complicate least-privilege access?
A: AI agents can change their path to a goal, so a role that looks narrow at provisioning time may still be too broad at runtime.
Q: What are the signs that AI security controls are lagging behind AI deployment?
A: Common warning signs include broad AI use with limited governance, unclear ownership for risk decisions, weak visibility into model usage, and inconsistent security testing before deployment.
Practitioner guidance
- Map every AI asset to an owner and a purpose Create an inventory of models, agents, datasets, and AI-facing integrations, then assign explicit business and technical ownership for each one.
- Scope non-human identity permissions for AI agents Give agents only the tools, files, and APIs they need for a specific task, and separate those permissions from human user accounts.
- Turn on runtime logging before enforcement Capture prompts, responses, model usage, and tool calls long enough to establish normal behaviour before blocking policy violations.
Bottom line: AppSec remains necessary for AI applications, but it does not govern prompts, models, agents, or the runtime behaviour that creates most AI-specific exposure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:16 pm
AppSec-only thinking fails once an AI feature becomes an operational system. The control model changes as soon as prompts, model outputs, and tool calls can influence real data or real workflows. Traditional security teams often certify the repository and the endpoint, then assume the runtime will behave like any other web service. It will not, and that is why AI governance has to extend beyond build-time assurance.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
A question worth separating out:
Q: How should security teams govern agent actions when prompts can be manipulated?
A: Treat the prompt as untrusted input and govern the action, not the language. Put an independent policy layer in the request path, enforce least privilege on each tool call, and deny anything that cannot be clearly authorised in context. The goal is to make a successful injection produce a denied request, not a compromised workflow.
👉 Read our full editorial: AI security tools and AppSec: where the legacy gap starts