Notifications
Clear all
Topic starter
10/06/2026 12:21 am
TL;DR: AI agents now access sensitive data, invoke workflows, and make multi-step decisions across enterprise systems, creating a non-deterministic risk model that traditional security playbooks were not built to handle, according to Zenity. The governance problem is no longer discovery alone, but controlling behaviour that changes at runtime and spans systems, permissions, and data flows.
NHIMG editorial — based on content published by Zenity: Securing the AI That Runs the Enterprise: Zenity + ServiceNow SecOps
Questions worth separating out
Q: How should security teams govern AI agents that can act across multiple systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped permissions, and continuous monitoring.
Q: Why do AI agents create blind spots for IAM and SecOps programmes?
A: AI agents create blind spots because they combine identity, decision-making, and action in one runtime subject.
Q: What breaks when AI agent permissions are not continuously reviewed?
A: What breaks is the assumption that the agent's risk profile stays fixed between review cycles.
Practitioner guidance
- Define agent inventory as a governance record Capture each agent's identity, owning workflow, permissions, APIs, data sources, dependencies, and external systems in one record so SecOps and IAM teams can investigate with context.
- Route agent drift into existing SecOps queues Send permission changes, prompt changes, integration failures, and unusual data access into the same case management and triage flow used for other security events.
- Review whether access review cycles fit agent behaviour Test whether your certification and recertification process can still answer who approved what when the subject can act, change scope, and complete tasks within a single runtime session.
What's in the full article
Zenity's full research covers the operational detail this post intentionally leaves for the source:
- Agent inventory fields and context mapping across workflows, APIs, permissions, and data sources
- AISPM workflow details for detecting misconfigurations, unsafe prompts, and integration weaknesses
- Continuous assessment patterns for tracking drift, risk scoring, and triage inside SecOps
- Cross-platform governance considerations for agents that operate outside a single system
👉 Read Zenity's analysis of SecOps-native AI agent security and governance →
AI agent security in SecOps: what changes for IAM teams?
Explore further
11/06/2026 2:06 am
Agent security is now a SecOps and identity governance problem, not a sidecar AI issue. When agents access data, invoke workflows, and trigger external actions, they behave like non-human identities with broader runtime variance than traditional service accounts. That means the security team cannot rely on static application assumptions or one-time onboarding checks. The implication is that agent governance must sit inside the same operational model that handles access, risk, and response.
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.
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, which shows the behaviour problem is already operational, not theoretical.
A question worth separating out:
Q: How should organisations respond when AI agent risk appears in SecOps?
A: Organisations should triage it like any other active security issue, with ownership, context, and remediation in the same queue used for operational incidents. The point is to avoid treating agent risk as a separate AI programme. It belongs in the control path where investigation and response already occur.
👉 Read our full editorial: AI agent security needs SecOps-native governance, not static controls
12/06/2026 3:40 am
Agent security is now a SecOps and identity governance problem, not a sidecar AI issue. When agents access data, invoke workflows, and trigger external actions, they behave like non-human identities with broader runtime variance than traditional service accounts. That means the security team cannot rely on static application assumptions or one-time onboarding checks. The implication is that agent governance must sit inside the same operational model that handles access, risk, and response.
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.
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, which shows the behaviour problem is already operational, not theoretical.
A question worth separating out:
Q: How should organisations respond when AI agent risk appears in SecOps?
A: Organisations should triage it like any other active security issue, with ownership, context, and remediation in the same queue used for operational incidents. The point is to avoid treating agent risk as a separate AI programme. It belongs in the control path where investigation and response already occur.
👉 Read our full editorial: AI agent security needs SecOps-native governance, not static controls
