Topic starter
10/06/2026 12:21 am
TL;DR: AI security posture tools can inventory models, pipelines, and data, but runtime behaviour remains the harder problem because LLM-powered agents can make API calls, access records, and invoke tools in ways scanners do not see, according to Orca Security. The real governance gap is that existing review and monitoring models assume AI behaviour is stable enough to be observed after the fact, which autonomous action breaks.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “The Orca Approach to Runtime AI Security”.
Key questions
Q: What breaks when AI security stops at posture instead of runtime behaviour?
A: Security teams lose visibility into the actions that matter most, such as API calls, record access and tool use.
Q: Why do MCP-based agents increase identity governance risk?
A: Because the agent can select tools and chain actions at runtime, which means authority is no longer fixed at issuance.
Q: How can security teams tell whether AI lifecycle controls are working?
A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current.
Practitioner guidance
- Map AI runtime identities and tool paths Inventory which workloads, agents and MCP servers can reach production data and which identities they use to do it.
- Correlate prompts with downstream actions Do not stop at prompt logging.
- Define policy boundaries for MCP usage Set separate rules for which MCP servers may connect to which applications, data sets and workflows, and require review of any integration that can move from prompt input to state-changing action.
Bottom line: AI posture management is necessary, but it does not explain what LLM-powered agents do once they begin calling tools and accessing live data.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/06/2026 2:05 am
Runtime AI security is now an identity problem, not only an AI problem. Once an LLM-powered agent can call APIs, access records, or invoke tools, the security question shifts from static model posture to live identity behaviour. That makes AI activity part of the non-human identity estate, because the system is executing with access that must be governed like any other workload or service identity. Practitioners should treat runtime visibility as identity control, not an optional add-on.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What should organisations do when AI activity crosses into cloud workloads?
A: They should treat the AI layer and the cloud layer as one control problem. If an AI system can pivot into applications, storage, or APIs, then the relevant question is not just whether the model is safe, but whether the connected workload and identity paths are governed as a single chain. That is where blast radius becomes visible.
👉 Read our full editorial: AI runtime security is exposing a gap posture tools miss
12/06/2026 3:40 am
Runtime AI security is now an identity problem, not just a cloud posture problem: once an AI system can call APIs, access records or invoke tools, the meaningful control boundary shifts from deployment state to live authority. Static inventory still has value, but it does not answer who or what actually exercised access. Practitioners should treat AI runtime behaviour as governed identity activity, not merely model telemetry.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should organisations do when AI agents can access external APIs and internal systems?
A: Organisations should put non-LLM permission controls around agents, so the model can suggest an action but cannot exceed its authorised scope. They should also apply input validation, rule-based guardrails between agents, secure vendor checks for third-party APIs, and logging that tracks data flow and detects anomalies in real time.
👉 Read our full editorial: AI runtime security is exposing a gap posture tools miss