Notifications
Clear all
Topic starter
06/09/2026 6:20 pm
TL;DR: AI applications only expose their real attack surface at runtime, and LEVO argues that traditional security tools miss the machine-to-machine interactions, identity drift, and data flows that determine whether agentic systems can move safely from pilot to production. The security model now has to follow execution, not just deployment, because governance fails when AI is treated like static software.
NHIMG editorial — based on content published by LEVO: Why enterprises who see and secure AI at runtime will own the next innovation frontier
By the numbers:
- Gartner reported a 750% surge in AI-agent inquiries between Q2 and Q4 2024.
- About 32% of enterprises exploring AI agents stall at pilot stage and are never deployed in production.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams handle delegated access when AI agents act on behalf of customers?
A: Security teams should treat delegated access as a separate governance layer, not as a normal login session.
Q: Why do traditional security tools miss many AI security risks?
A: Traditional tools are tuned for static systems, known boundaries, and conventional traffic patterns.
Q: What signals show that AI runtime controls are failing?
A: Warning signs include unexplained tool usage, access to data outside the expected workflow, repeated policy overrides, and behavioural drift across sessions.
Practitioner guidance
- Inventory every live AI asset Build a continuously updated inventory of agents, MCP servers, LLM applications, APIs, and third-party AI integrations.
- Trace prompts, responses, and downstream calls Instrument runtime tracing across prompts, responses, tokens, and API calls so teams can see how data moves through agent chains.
- Map authorization to execution Record who approved access, which non-human identity executed the action, and what token scope was active at the moment of execution.
What's in the full article
LEVO's full blog covers the operational detail this post intentionally leaves for the source:
- Runtime AI Security module capabilities for in-house and third-party asset discovery
- End-to-end data flow tracing across prompts, responses, tokens, and downstream API calls
- Identity and access clarity for who authorised versus who executed, including delegated tokens
- Operational health and cost metrics such as latency, error rates, loops, and token spend
👉 Read LEVO's analysis of runtime AI visibility and production control gaps →
Runtime AI visibility and the governance gap teams are missing?
Explore further
06/09/2026 6:21 pm
Runtime AI visibility is now a governance prerequisite, not a monitoring enhancement. AI systems create their true attack surface only when they execute, which means design-time reviews capture too little and perimeter controls see too late. That shifts governance from static approval to continuous observation of identities, data flows, and tool use. For NHI and IAM programmes, the practitioner conclusion is simple: if runtime behaviour is not visible, it is not governable.
A question worth separating out:
Q: Should organisations treat AI coding agents as part of IAM and PAM governance?
A: Yes, when those agents can act on code, data, or tools in ways that affect production risk. Their permissions should be scoped, reviewed, and audited like other privileged systems, especially when they interact with sensitive routes, secrets, or regulated data. The governance question is who can let the agent act, and under what policy.
👉 Read our full editorial: Runtime AI visibility is becoming the control plane for enterprise AI
