TL;DR: AI agents are now operating across SaaS, endpoints, and cloud platforms, creating a fragmented attack surface that traditional environment-bound tools cannot govern end to end, according to Zenity. The core issue is not agent adoption itself but the collapse of single-environment visibility and enforcement as agents move between tools, users, and workflows.
At a glance
What this is: Zenity argues that AI agent governance breaks down when agents span SaaS, endpoint, and cloud environments without a shared control plane for discovery, policy, and runtime enforcement.
Why it matters: IAM, PAM, and NHI teams need a cross-environment governance model because agent permissions, workflows, and tool use no longer stay inside a single security boundary.
Context
AI agent governance is the discipline of discovering, authorising, monitoring, and constraining software entities that act on behalf of users or workflows across multiple systems. The problem in this article is that those agents are no longer confined to one environment, so SaaS controls, endpoint controls, and cloud controls each see only a fragment of the same behaviour.
When agent identity, permissions, and runtime actions are spread across SaaS-managed agents, device-based agents, and cloud-built agents, traditional boundary-based security models lose the ability to explain what the agent is allowed to do end to end. That creates an identity governance gap, not just a monitoring gap, because access decisions now have to follow the agent across environments.
Key questions
A: Security teams should anchor AI governance in the identity layer and run it as a continuous operating model, not a policy exercise. Start with visibility into embedded and autonomous agents, then map data access and permissions, define role-based policy, enforce revocation and adaptive controls, and keep telemetry running for drift and offboarding. That sequence turns AI oversight into operational control rather than voluntary compliance.
Q: Why do traditional environment-specific tools fail to control AI agents effectively?
A: Because they each see only the slice of behaviour inside their own boundary. A SaaS tool can miss endpoint activity, an endpoint tool can miss cloud API calls, and a cloud control can miss the user-facing workflow that triggered both. That split breaks attribution, weakens enforcement, and leaves agent behaviour governed by partial context rather than full runtime intent.
Q: What are the signs that AI governance is too fragmented to support scale?
A: Common signs include duplicated governance tools, inconsistent policies across business units, and teams managing AI or data controls in isolation. Another warning is when organisations cannot confidently explain how data is governed across platforms. If governance only exists in pockets, scaling AI usually creates more risk, not less, because controls fail to follow the use case end to end.
Q: What should teams do when AI access expands beyond the original approval?
A: They should treat that expansion as a governance failure, not a normal exception. The right response is to contain the runtime path, verify the data and tools involved, and revisit whether the permission model reflects actual system behaviour. If not, the approval process has fallen behind execution.
Technical breakdown
Why environment-bound controls miss AI agent behaviour
Traditional enterprise controls are built around a single enforcement domain. CNAPP watches cloud workloads, EDR watches endpoints, and SaaS security tools watch application settings and access, but AI agents routinely cross those boundaries in one workflow. A Copilot action may begin in SaaS, call an API in cloud, and finish on a user device, which means no single control plane owns the full identity and action sequence. The result is fragmented visibility, inconsistent policy enforcement, and weak attribution for agent-caused actions.
Practical implication: map each agent class to every environment it can touch, then decide where policy must be enforced centrally rather than per tool.
How runtime governance differs from static configuration review
Configuration review tells you what an agent could access at setup time, but runtime governance tells you what it actually does when prompts, tools, and context change mid-session. That distinction matters because AI agents can chain prompts, call internal APIs, or escalate their own scope through connected tools after deployment. Governance therefore has to include continuous inspection of live behaviour, not only pre-deployment checks or permissions reviews.
Practical implication: treat runtime behaviour as a first-class control surface and build alerting for anomalous tool use, data movement, and privilege expansion.
Why SaaS-managed, device-based, and home-grown agents need one policy model
The article separates agents by where they execute, but their governance problem is the same: a software identity acting on behalf of a user or business process. SaaS-managed agents, endpoint-resident agents, and cloud-built agents all access data, trigger workflows, and invoke APIs, so policy fragmentation creates gaps in authorisation, monitoring, and revocation. A unified model is less about one tool than one identity and enforcement logic that can follow the agent wherever it runs.
Practical implication: standardise agent inventory, permissions, and response workflows so offboarding and containment work across all execution locations.
Breaches seen in the wild
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
- ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cross-environment agent governance is the new baseline: AI agents that move between SaaS, endpoint, and cloud environments invalidate security designs built around a single enforcement perimeter. The problem is not that each control is weak, but that no single tool sees the whole agent identity and action path. Practitioners should treat multi-environment visibility as the minimum viable control plane for agent governance.
Agent identity cannot be governed as a point-in-time entitlement: The article shows agents accessing data, triggering workflows, and invoking APIs across runtime contexts. That means permission review at provisioning time is no longer enough because the control decision must persist as the agent changes tools and environments. The implication is that access governance for agents must be continuous, not episodic, across the full execution surface.
Runtime inspection is now a governance requirement, not an optimisation: Zenity’s framing reflects a broader shift in the market toward behaviour-based enforcement for software entities that act autonomously on behalf of users. Whether the agent is SaaS-managed, local, or cloud-built, the governance question is the same: what did it actually do, with which permissions, in which environment. Practitioners should assume runtime controls will increasingly define operational readiness for agent programmes.
One policy engine will matter more than three separate control stacks: The article’s core message is that stitching together environment-specific tools leaves blind spots exactly where AI agents create risk. This is a governance architecture issue as much as a security tooling issue, because the policy model must survive movement across collaboration platforms, endpoints, and cloud services. Teams should evaluate whether their current operating model can express one agent policy across all three surfaces.
Named concept, control-plane fragmentation: AI agents are creating a control-plane fragmentation problem, where discovery, authorisation, and enforcement are split across tools that do not share a full identity picture. That fragmentation makes accountability harder and response slower because no single system owns the complete sequence of agent actions. The practical conclusion is that agent governance now needs cross-environment operating discipline, not just better point solutions.
From our research library:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Control-plane fragmentation: AI agent programmes fail when discovery, authorisation, and runtime enforcement live in separate tools that cannot share a complete identity picture. That creates governance gaps that are structural, not just operational, because the agent can cross SaaS, endpoint, and cloud boundaries without a single system owning the full sequence of actions.
Agent governance now depends on execution-context continuity: Teams need to know not only what an agent was permitted to do, but where that permission was exercised and whether it changed mid-session. Without that continuity, offboarding, containment, and audit evidence all become partial, which weakens the identity programme even when individual tools are configured correctly.
For practitioners
- Define a single agent inventory model Catalogue SaaS-managed, endpoint-based, and cloud-built agents in one inventory with owner, execution surface, and allowed tool paths.
- Unify agent authorisation policies Set a common policy model for data access, API invocation, and workflow triggering so permission decisions are consistent across environments.
- Add runtime inspection for live agent behaviour Monitor prompt chaining, internal API use, sensitive data access, and disallowed tool calls while the agent is running.
Key takeaways
- AI agents create a governance problem when they operate across multiple environments that are still secured as if they were separate domains.
- The article frames the issue as fragmented visibility and enforcement, which leaves one agent governed by several partial control planes.
- Practitioners need a unified inventory, policy model, and runtime inspection layer if they want agent governance to scale safely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents acting with identity and permissions across environments. |
| Recommendation — Apply ASI03 to govern agent privileges consistently across SaaS, endpoint, and cloud surfaces. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agent access depends on identity, auth, and cross-system trust boundaries. |
| NHI-05 — Overprivileged NHI | The article warns that agents often access more than a human equivalent would need. | |
| Recommendation — Harden agent authentication paths and verify that identities remain bound to approved execution contexts. Review agent permissions against least-privilege boundaries and remove excess access before deployment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cross-environment agent governance depends on consistent entitlement control and authorization. |
| Recommendation — Centralise entitlement governance so agent permissions are authoritatively managed across all environments. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes agents invoking APIs and moving across environments, which maps to abuse paths. |
| Recommendation — Map agent abuse cases to credential access and lateral movement to improve detection and response coverage. | ||
Key terms
- AI Agent Governance: AI Agent Governance is the set of policies, controls, and oversight practices used to direct how autonomous software agents behave. It defines allowed actions, approval paths, identity boundaries, logging, monitoring, and accountability so agent decisions remain traceable, constrained, and aligned with business, security, legal, and ethical requirements.
- Control Plane Fragmentation: Control plane fragmentation occurs when security decisions are split across multiple tools that do not share one authoritative view of access, device state, or policy enforcement. In MSP settings, this makes governance evidence harder to trust and increases the chance that exceptions become invisible.
- Runtime Inspection: Real-time monitoring of AI prompts and responses while the interaction is happening. Unlike point-in-time review, runtime inspection can detect sensitive data, prompt injection, and harmful outputs during the session, which is essential when risk changes faster than governance cycles.
- Agent Inventory: A governed record of every AI agent in use, including who created it, who can invoke it, what data it can reach, and what actions it can trigger. Without a current inventory, security teams cannot judge whether agent access still matches the business purpose.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org