Notifications
Clear all
Topic starter
01/07/2026 2:08 am
TL;DR: Gartner forecasts the average Fortune 500 will run 150,000 agents in production by 2028, up from fewer than fifteen in 2025, while only 13% of organisations say they have the governance to manage them, according to P0 Security. The real issue is not the interface, but the collapsed assumption that security can observe and govern agent activity at a network boundary.
NHIMG editorial — based on content published by P0 Security: Agentforce and Cortex aren’t SaaS features, they’re agent runtimes
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Scope the backing role to the minimum viable dataset Create purpose-built roles for each agent and remove reuse of analyst or admin permissions.
- Require deployment review before activation Make agent activation a control gate, not a self-service convenience.
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
👉 Read P0 Security's analysis of in-platform agent runtimes and NHI risk →
In-platform agent runtimes: are your IAM controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
01/07/2026 2:30 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Agent runtimes inside SaaS expose a new NHI governance gap
