Notifications
Clear all
Topic starter
10/06/2026 12:27 am
TL;DR: Orca says its Sensor can identify actual runtime AI usage across workloads, processes, MCP servers, exposure details, and identity context, while its new agents and reachability features aim to turn investigation, triage, and remediation into a more contextual workflow. That shift matters because visibility, accountability, and privilege decisions now have to follow AI activity in motion, not just static assets.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
Q: How should security teams govern runtime AI usage in cloud environments?
A: Start by correlating AI activity to the workload, process, identity, and tool path that initiated it.
Q: Why does shadow AI create an identity governance problem?
A: Shadow AI creates an identity governance problem because it behaves like unmanaged non-human identity.
Q: How do you know if AI triage is actually improving security outcomes?
A: Measure whether the triage decision can be reviewed, reversed, and tied back to concrete evidence.
Practitioner guidance
- Map runtime AI to identity context Instrument production environments so AI calls are correlated to the workload, process, MCP server, and identity that initiated them.
- Require explainable AI triage paths Do not allow AI-assisted alert suppression unless reviewers can inspect the reasoning and reverse the decision.
- Unify reachability with entitlement review Combine code reachability, runtime reachability, and identity exposure in the same prioritisation workflow.
What's in the full announcement
Orca Security’s full blog post covers the operational detail this post intentionally leaves for the source:
- How Orca Sensor correlates runtime AI activity to workloads, processes, MCP servers, and identity context.
- How the Threat Investigation Agent explains verdicts and supports rollback of false-positive designations.
- How Orca Missions groups findings into finish-line-based remediation work.
- How code reachability analysis is used alongside agentless and dynamic reachability to prioritise fixes.
👉 Read Orca Security’s analysis of runtime AI detection, triage, and reachability →
Runtime AI detection and MCP visibility: what changes for IAM teams?
Explore further
11/06/2026 2:12 am
Runtime AI visibility is becoming an identity governance requirement, not an optional telemetry layer. Once AI use is embedded in workloads, processes, and MCP servers, the question shifts from whether AI exists to which identities are invoking it and under what authority. That pushes AI observability into the same governance tier as workload identity and secrets control. Practitioners should treat runtime AI detection as part of identity control coverage, not as a separate security dashboard.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
A question worth separating out:
Q: Who is accountable when AI-driven remediation or suppression is wrong?
A: Accountability should sit with the owning security and platform teams, not with the model itself. If AI changes prioritisation, the organisation still needs a human owner for policy, review thresholds, and override authority. That is especially true when AI decisions affect vulnerable code, workload exposure, or service account scope.
👉 Read our full editorial: Runtime AI detection changes cloud security governance
12/06/2026 3:46 am
Runtime AI visibility is becoming an identity governance requirement, not an optional telemetry layer. Once AI use is embedded in workloads, processes, and MCP servers, the question shifts from whether AI exists to which identities are invoking it and under what authority. That pushes AI observability into the same governance tier as workload identity and secrets control. Practitioners should treat runtime AI detection as part of identity control coverage, not as a separate security dashboard.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
A question worth separating out:
Q: Who is accountable when AI-driven remediation or suppression is wrong?
A: Accountability should sit with the owning security and platform teams, not with the model itself. If AI changes prioritisation, the organisation still needs a human owner for policy, review thresholds, and override authority. That is especially true when AI decisions affect vulnerable code, workload exposure, or service account scope.
👉 Read our full editorial: Runtime AI detection changes cloud security governance
