Topic starter
19/08/2026 3:58 pm
TL;DR: AI security tools must be chosen by the failure mode they control, ActiveFence argues, because prompts, retrieval, outputs, memory, and tool use carry the risk. Runtime guardrails and audit evidence are what make a live AI system governable after deployment.
Editorial analysis by NHI Mgmt Group, based on content published by ActiveFence: “AI security tools: how to choose controls for GenAI apps, LLMs, and agents”.
Key questions
Q: Why do GenAI apps and agents need controls beyond AppSec and cloud security?
A: Because the AI system turns language, files, retrieved context, and tool access into behaviour.
Q: What breaks when AI systems are only protected by pre-release guardrails?
A: Static guardrails fail when the risk appears only after deployment, during live inference, tool use, and action execution.
Q: How should security teams evaluate AI security software for GenAI apps and agents?
A: Start with the asset under protection, then check whether the software covers the full lifecycle: discovery, pre-launch testing, runtime enforcement, production monitoring, and evidence retention.
Practitioner guidance
- Separate AI security from AI-powered SOC tooling Map each product to the failure mode it controls, such as prompt injection, data leakage, unsafe tool use, or SOC triage.
- Inventory GenAI apps, agents, and connected data paths Create a live register of sanctioned and shadow AI systems, including RAG sources, plugins, MCP connections, model endpoints, and workflow integrations.
- Enforce runtime guardrails on prompts, outputs, and tool calls Place policy checks in the live interaction path so malicious prompts, unsafe outputs, and unauthorized actions are blocked before they reach users or downstream systems.
Bottom line: AI security tools must be selected by the control failure they address, because AI-specific risks live in prompts, retrieval, outputs, memory, and tool use rather than in the model label itself.
Glossary terms: AI Security Tool, Runtime Guardrail, Shadow AI, AI governance evidence
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 hours ago by NHI Mgmt Group
19/08/2026 4:36 pm
AI security has become a lifecycle governance problem, not a model-selection problem. The article is right to separate tools that secure AI systems from tools that merely use AI to help the SOC. That distinction matters because risk accumulates in prompts, retrieval, outputs, tool calls, memory, and audit evidence, not in the model label alone. Practitioners should treat lifecycle coverage as the decisive selection criterion.
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: When should agent permissions be treated as identity governance rather than a feature setting?
A: As soon as the AI system can call tools, reach data, or trigger actions on behalf of a user or service. At that point, its permissions behave like non-human identity access and need scope, lifecycle, review, and revocation controls. Otherwise the agent becomes a standing access path with weak accountability.
👉 Read our full editorial: AI security tools need lifecycle controls for GenAI apps and agents