AI agent security governance now spans SaaS, cloud and endpoint

At a glance

What this is: Zenity’s award announcement positions agentic application security as a full-lifecycle control problem spanning discovery, posture, detection, prevention, and response for AI agents.

Why it matters: It matters because AI agents create identity, access, and audit gaps across programmes that were built for static applications, so IAM, PAM, and NHI teams need a governance model that tracks behaviour as well as entitlement.

👉 Read Zenity's analysis of AI agent security across SaaS, cloud and endpoint

Context

AI agent security is no longer a narrow prompt-filtering problem. The article describes a governance gap created when autonomous systems can access SaaS, cloud, and endpoint resources, invoke tools, and move through workflows that existing IAM and security monitoring often treat as ordinary application activity. For identity programmes, that means agent behaviour has to be governed as a distinct access pattern, not folded into generic application security.

The practitioner issue is full lifecycle control. Discovery, posture management, runtime detection, inline prevention, and response have to work together because an agent can be both a subject of access control and an actor that changes its own execution path. The topic sits at the intersection of NHI governance and agentic AI identity, which is exactly where static policy alone starts to lose coverage.

Key questions

Q: How should security teams govern AI agents that operate across SaaS, cloud, and endpoints?

A: They should treat each agent as an identity with explicit scope, observable behaviour, and cross-environment permissions. Governance needs discovery, posture assessment, runtime enforcement, and audit correlation across every system the agent can reach. If one control plane cannot reconstruct the full path, the programme still has a blind spot.

Q: What breaks when AI agent security is handled like ordinary application security?

A: Application security assumes a relatively stable workload boundary and a predictable request path. AI agents can select tools, access data, and continue executing in ways that change the path mid-workflow. When teams treat them like static apps, they miss the identity and authorisation layer where real risk appears.

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

A: They should test whether they can see the agent from discovery through action and response, not just whether the agent was approved. Working governance produces a complete trail of identity, tool use, data access, and enforcement decisions. If those pieces cannot be joined, the control model is incomplete.

Q: Why do AI agents create new requirements for IAM and PAM teams?

A: Because the same identity may need access to data, tools, and escalation paths that change at runtime. IAM must govern scope and lifecycle, while PAM must constrain high-risk actions in the moment they are requested. Static entitlement review alone cannot contain a behaviour-changing actor.

Technical breakdown

Agent-centric security for autonomous workflows

Traditional application security assumes a stable application boundary, predictable calls, and controls that can be applied at deployment time. Agentic application security has to account for runtime decision-making, where the system can choose tools, data sources, and next actions as it works. That changes the security object from a static workload to a behaviour-bearing identity that can consume permissions differently from one session to the next. The core technical challenge is correlating intent, action, and data movement across the full workflow rather than inspecting a single request or prompt in isolation.

Practical implication: Model AI agents as identities with observable behaviour and enforce controls that evaluate actions in context, not just at provisioning time.

Full-lifecycle coverage across SaaS, cloud, and endpoint

The article’s emphasis on full-lifecycle coverage is important because agent activity is distributed. A single agent can start in a SaaS application, call cloud services, and trigger actions on an endpoint, which means no one control plane sees the whole path by default. That creates blind spots in audit trails, entitlement review, and incident response unless the security architecture normalises events across those environments. From an identity perspective, this is a cross-domain governance problem, not a point-product monitoring problem.

Practical implication: Correlate agent identity, tool invocation, and data access across all platforms where the agent can act, or the audit trail will remain incomplete.

Real-time prevention versus post-event review

The article contrasts runtime prevention with offline visibility. For AI agents, post-event review is often too late because the risky action may already have occurred, the data may already have moved, and the agent may have already chained further actions. That is why detection must be paired with inline prevention and response logic. In practice, this means policy must be enforceable at the moment the agent requests access or invokes a tool, not only when a human reviews a log later.

Practical implication: Place enforcement at the tool and data boundary so risky agent actions can be blocked before they propagate across the workflow.

Threat narrative

Attacker objective: The objective is to use agent access and workflow trust to reach data, systems, and actions that expand the blast radius of a single identity.

1. Entry occurs when an AI agent is granted access to SaaS, cloud, or endpoint resources and begins operating inside ordinary enterprise workflows.
2. Escalation occurs when the agent invokes tools, reaches data sources, or extends its own execution path beyond what the original operator expected.
3. Impact occurs when the agent performs actions that create blind spots, move sensitive data, or execute workflows that security teams cannot easily reconstruct after the fact.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent governance is becoming an identity control problem, not just an application security problem. The article reflects a market shift toward treating agents as active actors that need discovery, posture, and runtime oversight across environments. That matters because the security failure is no longer confined to one model invocation or one prompt. Practitioners need to think in terms of agent identity, tool authority, and observable behaviour across the full execution path.

Full-lifecycle coverage is the right framing because AI agents do not stay inside a single control domain. A SaaS agent may depend on cloud APIs and still trigger endpoint-side effects, which means audit and response have to span multiple planes. The governance question is not whether a control exists, but whether it sees the same identity consistently as it moves across systems. That is the point at which fragmented monitoring becomes an assurance gap.

Static application controls fail when the actor can choose actions at runtime. Legacy security assumes the boundary, the request shape, and the sequence of access are known in advance. That assumption breaks when the agent decides which tool to call next and how to proceed. The implication is that identity programmes must treat runtime behaviour as part of authorisation, not as an after-the-fact logging concern.

Named concept: agent workflow visibility gap. The article highlights the gap between seeing an AI agent exist and seeing what it actually did across SaaS, cloud, and endpoint environments. That gap is what leaves compliance, incident response, and access governance out of sync. Once the workflow is distributed, incomplete telemetry becomes a governance issue, not just a monitoring issue.

Security leadership will increasingly judge AI agent programmes by whether they can prove controlled behaviour, not merely approved deployment. Awards and market recognition are following vendors that can describe lifecycle governance, real-time enforcement, and cross-environment traceability in one model. The field is moving toward measurable control over agent actions, and practitioners should expect governance evidence to matter as much as deployment count.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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, according to SailPoint research.
• For a broader framing of the control problem, see OWASP Agentic AI Top 10 for the runtime risks that govern agent tool use and workflow abuse.

What this signals

Agent workflow visibility gap: enterprise teams are moving faster on deployment than on governance, which means the operational problem is no longer whether AI agents exist but whether they can be observed end to end. With 98% of companies planning to deploy more agents, the programme risk is that control design will continue to lag actual usage. That makes lifecycle evidence, tool-level telemetry, and cross-platform traceability the practical priorities.

The right response is to align agent governance with the same discipline used for privileged human and machine access, then extend it to runtime behaviour. Where a traditional IAM programme can rely on static certification cycles, agentic systems need continuous observability and inline policy enforcement. For a framework lens, the OWASP Agentic AI Top 10 is the cleaner reference point than legacy application security models.

As agent fleets expand, identity teams should expect the conversation to move from approval to proof. The question will be whether an organisation can demonstrate what an agent accessed, which tools it invoked, and where its actions were stopped. That is a governance maturity issue, not just a detection issue.

For practitioners

• Map agent identities to every control plane they can touch. Build an inventory that ties each AI agent to the SaaS applications, cloud services, and endpoints it can reach. Include tool invocation paths, not just named integrations, so the review covers the full execution path rather than a single platform.
• Enforce runtime policy at the tool boundary. Block or step up sensitive actions when an agent requests data access, external calls, or privileged workflow steps that exceed its declared purpose. Do not rely on post-event log review to catch abuse after the action has already propagated.
• Correlate agent behaviour with identity evidence. Link agent discovery records, posture data, and audit trails so incident responders can reconstruct who or what acted, which tools were used, and which data paths were involved. Without that correlation, investigations will remain partial and remediation will lag.
• Treat cross-environment access as a single governance problem. Review SaaS, cloud, and endpoint permissions together for each agent because fragmented ownership hides privilege creep. The control objective is to reduce agent blast radius across the whole workflow, not to optimise one platform in isolation.

Key takeaways

• AI agent security now sits at the intersection of identity, workflow, and runtime control, not just application hardening.
• The evidence point is clear: agent deployment is accelerating faster than governance, leaving blind spots in auditability and enforcement.
• Practitioners should focus on cross-environment identity correlation and inline control, because post-event review cannot contain agent behaviour once it spreads.

Key terms

• Agent-centric security: A security model that treats an AI agent as the primary unit of governance instead of the application hosting it. The model tracks what the agent can access, which tools it can invoke, and how its actions change the risk posture across the workflow.
• Agent workflow visibility gap: The difference between knowing an AI agent exists and being able to reconstruct everything it did across systems. This gap appears when discovery, logging, and enforcement are split across SaaS, cloud, and endpoint environments, leaving security teams with incomplete evidence.
• Runtime enforcement: A control approach that evaluates and blocks risky actions while the AI agent is executing, rather than after the event. In practice, it is the difference between reviewing a log and stopping an unauthorised tool call before it reaches a sensitive system.
• Full lifecycle coverage: Coverage that follows an identity from discovery through posture, monitoring, prevention, and response. For AI agents, it means controls must persist across the entire operating path, because risk does not stop at provisioning or approval.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Zenity: Zenity named Top InfoSec Innovator for AI agent security in 2025. Read the original.