Agent runtimes inside SaaS expose a new NHI governance gap

At a glance

What this is: This analysis argues that in-platform AI agents in SaaS are really agent runtimes with non-human identity implications, and that existing network-layer controls cannot see or govern their internal activity.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern the role behind the agent, not just the SaaS application boundary, or they will miss privilege abuse entirely.

By the numbers:

• Gartner forecasts that the average Fortune 500 will run 150,000 agents in production by 2028, up from fewer than fifteen in 2025.
• Only 13% of organizations think they have the governance to handle it.
• A January 2026 survey of 235 CISOs at large enterprises found that 71% use AI tools that access core business systems like Salesforce and SAP.
• Only 16% effectively govern that access.

👉 Read P0 Security's analysis of in-platform agent runtimes and NHI risk

Context

Agent runtimes inside SaaS platforms are AI agents that execute inside the application boundary rather than outside it. That matters because traditional security tooling assumes it can inspect traffic at the edge, but these agents read, transform, and write data without crossing a network boundary your controls can reliably observe.

For identity teams, the real problem is not that the platform has AI features. It is that those features inherit the privilege of the user or service identity that activates them, which turns a business-user workflow into an NHI governance problem. Once the runtime lives inside the data platform, lifecycle, scoping, and review must move closer to the role that powers it.

Key questions

Q: How should security teams govern in-platform AI agents inside SaaS applications?

A: Security teams should govern in-platform AI agents as non-human identities with their own owner, role, and lifecycle. The key is to control the backing entitlement, not the UI that creates the agent. That means narrow permission sets, activation review, connector inventory, and identity monitoring tied to the platform role the agent inherits.

Q: Why do SaaS-based AI agents create more risk than their feature labels suggest?

A: They create more risk because the label hides the real security boundary. The agent runs where the data already lives, so the effective blast radius is the role behind it, not the application surface. If that role is broad, the agent can query, transform, and expose more data than the business user intended.

Q: What breaks when network security is used to govern internal SaaS agents?

A: Network security breaks because the agent’s critical actions do not necessarily traverse an observable boundary. DLP, CASB, SSE, and endpoint tools are useful for external movement, but they cannot fully see internal read and write operations inside the platform. Governance has to move into entitlement control and identity telemetry.

Q: Who should own review and accountability for agent-created access in SaaS platforms?

A: Accountability should sit with IAM, platform owners, and the business function that requested the agent, with security enforcing the review gate. The important question is who can approve the role, the data sources, and the connectors before activation. If nobody owns that decision, the agent is already under-governed.

Technical breakdown

Why in-platform agents evade network security controls

In-platform agents such as Agentforce or Cortex operate inside the SaaS trust boundary, so their most important actions never appear as suspicious egress traffic. DLP, CASB, SSE, and endpoint tools were built for data movement across boundaries, not for workloads that query records, summarize them, and write results back inside the same platform. If the agent stays inside CRM or warehouse infrastructure, the control point shifts from transport inspection to identity and entitlement governance.

Practical implication: inventory agent activity where the platform executes it, not where the network observes it.

Why privilege inheritance turns features into non-human identities

These agents inherit the access of the role that invokes them, which means the effective security model is the underlying identity, not the feature label. A business user may create the agent through low-code tooling, but the agent can still reach whatever that user, analyst, or service account can reach. That makes permission sets, row-level controls, masking policies, and activation gates the real enforcement surface.

Practical implication: scope the backing role narrowly and treat agent activation as a privileged identity event.

What MCP integrations change about exposure paths

When a platform agent uses MCP integrations or other internal connectors, the agent can move from internal query execution to externalized action without leaving the vendor ecosystem. That expands the attack surface from data access alone to delegated tool use, prompt-driven execution, and unintended outbound actions. The critical issue is not the interface itself, but the fact that the agent can chain access, context, and execution from within a trusted platform.

Practical implication: govern every connector, topic, and data path as part of the identity lifecycle for the agent.

Threat narrative

Attacker objective: The attacker aims to use trusted in-platform automation to reach data and actions that the underlying role already permits, while bypassing network-centric inspection and review.

1. Entry occurs when a user creates an in-platform agent through low-code tools and it inherits an existing business or admin role.
2. Escalation follows when the agent uses that inherited privilege to query broader datasets, execute internal actions, or chain through connectors without additional review.
3. Impact is unauthorized data exposure or destructive action inside the SaaS platform, while security tools positioned at the network boundary never see a clean intercept point.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

In-platform agents are named non-human identities, not SaaS features: That distinction matters because the control problem is entitlement, not interface. Once an agent runs where the data lives, conventional inspection at the network edge stops being the primary defense. Practitioners should treat activation, role scoping, and lifecycle as identity controls, not application settings.

Privilege inheritance creates an identity blast radius that most teams are underestimating: The agent can only do what the underlying role permits, but that is still enough to expose regulated data or trigger destructive actions. The named concept here is identity blast radius, meaning the full set of records, actions, and connectors an agent can affect because it inherits a human or service role. The practitioner conclusion is to narrow the backing role before deployment, not after an incident.

Boundary-based security assumptions fail when the runtime is the platform: Network tools assume observability at ingress or egress, but these agents operate within CRM and warehouse trust zones. That means the governance model has to move toward identity-aware monitoring, deployment gates, and entitlement review. The practitioner conclusion is that SaaS agent governance belongs in IAM and NHI operations, not only in the security stack.

Democratized creation without differentiated authorization is a control failure: Low-code builders let business users create agents quickly, but speed does not justify inherited privilege. The governance gap is not creation itself, it is letting creation and access reuse the same broad role. The practitioner conclusion is to separate who can define an agent from what the agent can reach.

This category will force IAM, PAM, and NHI teams to converge on runtime governance: The more agents are embedded into core SaaS systems, the less useful it becomes to manage them as isolated application features. Lifecycle, review, and scoping have to follow the agent as a workload. The practitioner conclusion is to build one governance path for human, service, and agentic access where the same role family is in play.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For deeper lifecycle context, Ultimate Guide to NHIs shows why visibility, rotation, and offboarding must be designed together.

What this signals

Identity blast radius: As SaaS platforms embed more internal agents, the control problem shifts from traffic inspection to entitlement scope. Teams that still anchor governance in CASB or SSE alone will miss the place where access is actually exercised: inside the role that powers the agent.

The programme signal is clear. If you cannot enumerate which identities create, activate, and own in-platform agents, you do not yet have a defensible NHI governance model. The next step is to bring those agents into the same lifecycle and review cadence used for privileged service accounts.

The visibility gap is structural rather than accidental. With only 5.7% of organisations reporting full visibility into their service accounts, according to Ultimate Guide to NHIs, in-platform agents will widen the blind spot unless identity telemetry moves closer to the workload.

For practitioners

• Treat in-platform agents as named non-human identities Classify every agent that executes inside SaaS, warehouse, or CRM systems as a governed identity with an owner, purpose, role, and revocation path. Do not let it sit in the application inventory as a generic feature.
• Scope the backing role to the minimum viable dataset Create purpose-built roles for each agent and remove reuse of analyst or admin permissions. Apply row-level access, masking policies, and task-specific grants so the agent cannot inherit a broader business identity than necessary.
• Require deployment review before activation Make agent activation a control gate, not a self-service convenience. Review the prompt, the connector list, the data sources, and the allowed write actions before the first production run.
• Monitor platform-native agent activity in identity workflows Feed query volume, schema access, outbound recipients, and unusual execution times into the same workflows used for privileged identity monitoring. SaaS admin views are not enough when the runtime is already inside the data platform.
• Apply zero standing privilege to the role behind the agent Mint the effective permissions only when the task begins and revoke them when the task ends. If the agent needs always-on access today, that is a sign the role has not been scoped tightly enough.

Key takeaways

• In-platform AI agents behave like non-human identities because they inherit the privilege of the role that activates them.
• Network-centric tools cannot reliably govern agent activity that stays inside SaaS trust boundaries and never crosses the edge.
• Teams need role scoping, activation review, and identity monitoring before these agents are allowed into production.

Key terms

• In-Platform Agent: An in-platform agent is an AI workload that executes inside a SaaS or data platform rather than calling out from an external system. Its security posture is determined by the platform role it inherits, the data it can reach, and the connectors it can invoke.
• Identity Blast Radius: Identity blast radius is the full set of records, actions, systems, and connectors an identity can affect when access is overly broad. For agents, the concept captures how inherited privilege turns a small configuration choice into a large operational exposure.
• Activation Gate: An activation gate is the review point that must be satisfied before an agent or workload is allowed to operate in production. It is an identity control, not a product feature, because it decides whether the runtime is permitted to act at all.
• Privilege Inheritance: Privilege inheritance is the transfer of access from a human user or service identity to the agent or workload they create. In SaaS agents, it is the mechanism that turns low-code convenience into overbroad operational reach if the backing role is not narrowed first.

What's in the full article

P0 Security's full article covers the operational detail this post intentionally leaves for the source:

• Platform-specific control points for Salesforce Agent Builder and Snowflake Cortex deployments
• Examples of how permission sets, row-access policies, and masking controls change the agent risk profile
• Details on the PromptArmor, ForcedLeak, and PipeLeak research paths that illustrate the failure mode
• Practical distinctions between deployment gates, activation controls, and runtime monitoring

👉 P0 Security's full post covers platform-specific control points, breach examples, and governance choices.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.