Topic starter
06/09/2026 6:21 pm
TL;DR: Security for AI and AI for Security need separate backlogs, budgets and KPIs, with every AI call mediated by a gateway, schema-first outputs, provenance controls and continuous assurance because untrusted inputs can become instructions and outputs can become actions, according to LEVO. The governance lesson is that replayable evidence, bounded tool use and denial by default now define whether AI is operable or merely experimental.
Editorial analysis by NHI Mgmt Group, based on content published by LEVO: “AI Security: The Complete Guide for 2026”.
Key questions
Q: How should teams stop malformed AI output from causing side effects?
A: Treat AI output as untrusted until it passes a strict schema and policy check.
Q: Why do AI gateways matter for RAG and agent workflows?
A: Because they turn diffuse model risk into a single enforcement point.
Q: What breaks when AI agent provenance is not tracked?
A: You lose the ability to connect an action back to the delegator, scope, and context that authorised it.
Practitioner guidance
- Separate Security for AI from AI for Security Create distinct backlogs, owners, budgets and KPIs for protecting AI systems versus using AI in SecOps and support workflows.
- Enforce gateway policy on every AI route Route all model, retrieval and tool traffic through a policy gateway that can apply input checks, output rules, budgets, approvals and trace export.
- Require schema validation before side effects Use schema-first outputs and typed adapters so downstream systems reject malformed or out-of-policy responses before they trigger action.
Bottom line: AI security fails when models, RAG and agents are governed as one problem, because the controls needed for input policy, provenance and tool execution are different.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 6:22 pm
AI governance debt is now an operational risk, not a future control gap: organisations that treat model security, RAG security and agent security as one workstream create blind spots between policy, provenance and execution. The vendor's framing is correct to separate Security for AI from AI for Security, because ownership and success metrics differ across those programmes. Practitioners should expect audit pressure to focus on evidence, not intent.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should security teams govern AI agents that inherit authority from other identities?
A: Security teams should govern AI agents by tracking identity lineage, not just credentials. That means recording the originating identity, the delegated authority path, and the runtime context for each action. If an agent can inherit permissions from humans, services, or other agents, policy has to evaluate the full chain before access is granted or continued.
👉 Read our full editorial: AI security needs separate controls for models, RAG and agents