Notifications
Clear all
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.
NHIMG editorial — based on content published by LEVO: a practical playbook for securing models, RAG and agentic AI across the stack
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI systems that can act without human approval?
A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review.
Q: Why do AI agents make IAM and NHI risk harder to manage?
A: AI agents can request tools, call APIs, and even create new infrastructure at machine speed, which multiplies identity events and privilege decisions.
Q: What are the warning signs that an AI workflow is too risky to automate?
A: Look for free-form outputs that are parsed downstream, missing approval capture, weak source provenance, no rollback path and tool access that is broader than the task requires.
Practitioner guidance
- Implement a gateway on every AI route Route all model calls through a boundary that enforces input policy, output policy, budgets, approvals and trace export before any downstream action is possible.
- Make structured schemas mandatory for effectful outputs Require typed output for tool calls, automations and any path that can trigger a side effect, then reject malformed responses instead of parsing them downstream.
- Bind AI workloads to signed sources and manifests Sign corpora, indexes and retrieval manifests, attach source IDs to every answer, and quarantine or revoke data that cannot be proven.
What's in the full article
LEVO's full research covers the operational detail this post intentionally leaves for the source:
- Reference blueprints for thin-wrapper LLM apps, enterprise agent gateways and private RAG deployments
- One-week rollout patterns for gateways, evals, observability and evidence bundle creation
- Concrete acceptance tests for schema pass rates, injection block rates and replay times
- Governance and compliance artefacts for AI RMF, ISO/IEC 42001 and audit-ready evidence bundles
👉 Read LEVO's full playbook for securing models, RAG and agentic AI →
AI security, RAG and agents: what controls should teams separate?
Explore further
06/09/2026 6:22 pm
Security for AI and AI for Security are different control problems, not one programme. The article correctly separates AI stack protection from AI-enabled defence, because they fail differently and are governed differently. One is about preventing model, retrieval and tool compromise. The other is about using AI to accelerate analyst work without losing evidence, accountability or approval boundaries. Practitioners should separate ownership, backlogs and KPIs before they collapse both into one budget line.
A question worth separating out:
Q: How do organisations decide whether AI agent access reviews should be automated or manual?
A: Organisations should automate the repetitive parts of access review when AI agents create large, fast changing permission sets, then reserve human judgment for high risk exceptions. Automated reasoning helps reduce reviewer fatigue and surface outliers sooner, but it still needs policy guardrails, clear ownership, and escalation paths for privileged or sensitive access.
👉 Read our full editorial: AI security needs separate controls for models, RAG and agents
