ServiceNow and Zenity tighten AI agent governance in SecOps

At a glance

What this is: Zenity and ServiceNow are tying AI agent security into SecOps, with built-in visibility, posture management, vulnerability assessment and remediation for autonomous agents.

Why it matters: IAM, PAM and security teams now have to govern AI agents as active identities inside operational workflows, where visibility and response need to happen together.

Context

The governance gap is straightforward: enterprises are deploying autonomous AI agents into live workflows faster than they can inventory them, understand their permissions, or track what data and systems they touch. In this model, the primary problem is not model quality but identity control over agents that can act across multiple business services.

Zenity's partnership with ServiceNow places AI agent risk reduction inside SecOps rather than leaving it as a separate review process. That matters because AI agents now behave like operational identities that need continuous visibility, posture evaluation, and remediation paths inside the same systems teams already use for security response.

Key questions

Q: How should security teams govern AI agents that run long, multi-step workflows?

A: Security teams should require durable execution, full event history, and clear ownership for every multi-step agent workflow that touches sensitive data or privileged tools. If the agent can lose state on failure, the organisation cannot reliably audit what happened or prove which actions were completed versus replayed.

Q: What breaks when an AI agent is not part of identity inventory?

A: When an AI agent is not part of identity inventory, governance breaks at the point of discovery. Teams cannot reliably answer who owns the agent, what credentials it uses, or what systems it can reach. That makes access review, offboarding, and incident response incomplete because the trusted entity was never formally brought under control.

Q: How do organisations know whether AI agent governance is actually working?

A: Look for evidence that risky actions are blocked before execution, not just logged afterward. Strong governance produces fewer unauthorized state changes, fewer surprise costs, fewer silent data edits, and clear separation between retrieval, decision, and write privileges. If agents can still alter production without hard stops, governance is cosmetic rather than effective.

Q: How do security teams know if an AI agent has too much access?

A: Look for agents that can reach multiple systems without task-specific limits, use persistent tokens, or touch high-value services such as email, chat, cloud consoles, and file stores. A healthy deployment leaves a clear audit trail of what the agent can do, what it actually did, and which credentials it used.

How it works in practice

Agent inventory in SecOps

Agent inventory is the first control layer because you cannot govern what you cannot enumerate. In this model, each AI agent needs to be tied to connected business services, dependencies, access paths and data touchpoints. ServiceNow CMDB becomes the operational system of record, while Zenity's signals enrich it with security context so teams can see where agents exist and what they can reach. The mechanism matters because agent sprawl often hides across platforms, business units and shadow workflows. Without a living inventory, every downstream control becomes partial. Practical implication: build a current inventory of AI agents, their service connections and their data access before attempting policy enforcement.

Practical implication: build a current inventory of AI agents, their service connections and their data access before attempting policy enforcement.

AI security posture management for autonomous agents

AI security posture management for agents is different from traditional configuration review because the relevant questions are behavioural and relational, not just technical. Teams need to know how agents are constructed, what permissions exist, who can access them, what dependencies they inherit and which systems they can influence. That turns posture into a governance view across identity, access and data exposure. It also exposes when an agent has more reach than its task requires, or when business workflows grant access that was never intended for machine execution. Practical implication: assess agent posture as a combination of permissions, dependencies and data reach, not as a one-time build checklist.

Practical implication: assess agent posture as a combination of permissions, dependencies and data reach, not as a one-time build checklist.

Continuous remediation for agent exposures

Continuous remediation matters because agent risk changes as workflows, integrations and permissions change. A static approval model assumes the risky state can be reviewed later, but agentic environments can accumulate misconfigurations, excessive permissions, compliance gaps and data exposure faster than periodic review cycles can catch them. By feeding exposure findings into Security Operations workflows, remediation becomes part of the operational loop rather than an afterthought. That is particularly relevant when the issue is not one compromised account, but a broad set of high-risk agent exposures that expand attack surface across environments. Practical implication: route high-risk AI agent exposures into SecOps workflows with defined ownership and closure criteria.

Practical implication: route high-risk AI agent exposures into SecOps workflows with defined ownership and closure criteria.

NHI Mgmt Group analysis

AI agent governance is becoming a SecOps problem, not a sidecar policy exercise. The article shows that visibility, posture management and remediation are moving into the operational systems where security teams already work. That is a practical shift because autonomous agents are no longer experimental objects at the edge of the programme. They are becoming part of live business workflows, which means the control plane has to sit where incidents and exposures are handled.

The control gap is not simply access, but agent lifecycle visibility. Enterprises need to know what agents exist, how they are built, what systems they touch and what data they access. That is classic governance logic applied to a new subject. The implication is that AI agent oversight has to behave more like an identity and access programme than a point solution for model safety.

Agent inventory, posture and remediation should be treated as one continuous control chain. Separating discovery from assessment and assessment from response creates delay and blind spots. In autonomous environments, that delay matters because agent behaviour changes as integrations, permissions and dependencies change. Practitioners should treat the combined workflow as the minimum viable governance pattern for AI agents.

Governance for autonomous agents now depends on runtime evidence, not just approval artefacts. The named concept here is runtime governance gap: the difference between having a policy on paper and having live controls that can see, assess and remediate agent behaviour in production. That gap widens when organisations let agents scale across multiple business services without a connected control model. The implication is that oversight must follow the agent into execution, not stop at deployment.

AI agent oversight is converging with broader identity security practice. The same discipline that governs entitlements, dependencies and remediation in human and machine identity programmes now has to apply to autonomous agents. The article reflects a market direction in which SecOps, IAM and AI governance are no longer separate conversations. Practitioners should expect these operating models to merge.

From our research library:

• 54% of organisations are actively deploying AI agents across workflows, yet only 21% report a mature governance model for agentic AI.
• Read next: Agentic AI Security Guide

What this signals

Runtime governance gap: enterprises that separate agent discovery from remediation will keep finding exposures after the fact instead of governing behaviour in production. For AI agents, the decisive issue is whether the control model can follow the agent into execution and back out again.

Security teams should expect AI agent oversight to converge with identity governance because the questions are already the same: what exists, who can reach it, what it touches and how quickly risk can be closed. The organisations that treat SecOps as the operating layer for agent governance will move faster than those keeping AI risk in a separate review track.

For practitioners

• Map every agent to a business service Create a living inventory that records each agent, its connected business services, dependencies, data access and owning team. If the agent cannot be tied to a service and a named owner, it is not governable inside SecOps.
• Review agent posture as a security control Assess how each agent is constructed, what permissions it has, who can access it and what systems it can touch. Use that view to identify excessive permissions, exposed data paths and compliance gaps before they become operational drift.
• Route exposures into operational remediation Send high-risk agent findings into existing Security Operations workflows so vulnerability closure, policy exceptions and ownership decisions happen in one tracked process rather than across separate queues.
• Separate agent discovery from task approval Do not assume a one-time approval covers later changes in data access, dependencies or integrations. Re-evaluate agent scope whenever the workflow, connected system or privilege set changes.

Key takeaways

• AI agent governance is shifting into SecOps because discovery, posture and remediation now need to work as one control chain.
• The article's core signal is operational, not theoretical: agent visibility must include services, data reach, dependencies and permissions.
• Teams that cannot connect AI agent findings to a live remediation workflow will not have meaningful control, only documentation.

Key terms

• AI agent inventory: An AI agent inventory is a complete record of autonomous or semi-autonomous software entities, including their permissions, tools, and reachable resources. It is a governance baseline because teams cannot review, restrict, or remediate agent access until they know exactly what the agent estate contains.
• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• Governance Gap: A governance gap is the distance between knowing an asset exists and being able to enforce policy on it. In identity programmes, it appears when discovery, review, and enforcement are split across different tools or teams, leaving access partially visible but not truly controlled.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.