Your security stack doesn’t know the difference between SaaS features and agent runtimes and that gap is already evident in production.
Both are configured by business users through low-code builders. Both inherit the privileges of the role that invokes them. Both run inside the platform that holds the data — which means the agent never crosses the network boundary your security stack is watching.
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. The agents driving most of that volume aren’t bespoke coding agents. They’re the in-platform agents that ship as features of the SaaS tools you already pay for — and they’re exactly what your CASB, endpoint stack, and SSE traffic logs weren’t built to see.
The agent that never leaves the platform
Network-layer security tools — DLP, CASB, SSE, endpoint controls — were built on the assumption that data movement is observable at a boundary. Agentforce reads CRM records, summarizes them, writes back to CRM. Cortex queries warehouse tables and returns answers to other Snowflake-resident workloads, or out through Cortex’s MCP integrations. The traffic that matters is entirely internal to the platform.
Palo Alto’s SaaS security team put it plainly: network and endpoint security can’t see AI agent activity as it moves through SaaS applications. The agent is a workload inside the platform’s trust boundary. The data it can reach is whatever the underlying role can reach. There’s no decryption point at egress where an inspection control could intervene.
Democratized creation, undifferentiated authorization
Salesforce markets Agent Builder as something anyone can use — sales managers, support leads, RevOps analysts can ship an agent in an afternoon. Cortex is the same story: a Snowflake analyst with the right role can stand up a Cortex Agent that queries production tables, executes SQL through Cortex Code, and exposes results through MCP, with no second set of eyes between the prompt and the data.
Every one of those agents inherits the access of the user or service identity that owns it.
Salesforce’s Einstein Trust Layer has real controls: zero data retention, toxicity detection, audit logging, prompt isolation. But the blast radius is the role behind the agent. ForcedLeak (CVSS 9.4, September 2025) embedded malicious instructions in a Web-to-Lead form and exfiltrated CRM data to a Salesforce-allowlisted domain that had expired and was available for $5. Capsule Security’s parallel PipeLeak research found a separate injection chain in the same product — and reported that, even after Salesforce’s remediation, it still works against Custom Topics, which account for the majority of enterprise Agentforce deployments.
Cortex shows the same failure mode. PromptArmor’s March 2026 research hijacked Cortex Code into executing arbitrary code with the agent’s cached Snowflake credentials and dropping tables on the way out. Patches close specific exploits. They don’t change the fact that the agent runs at the privilege of the role that invoked it.
The data is right there
Salesforce holds customer records, opportunity data, contact PII, financial pipeline. Snowflake holds whatever made it into the warehouse — which in most organizations is the broadest single pile of regulated data in production. An agent embedded in these platforms isn’t “an agent that connects to data.” It’s a workload that runs where the data already lives, with whatever privilege the underlying role carries.
A January 2026 survey of 235 CISOs at large enterprises: 71% use AI tools that access core business systems like Salesforce and SAP. Only 16% effectively govern that access. 92% lack full visibility into their AI identities.
What to do about it
- Treat in-platform agents as named non-human identities. They’re not features. They’re workloads. Apply the same JIT, scoping, and lifecycle discipline you use for service accounts.
- Scope the underlying role specifically for the agent. Don’t let an Agentforce or Cortex agent ride on an existing analyst or admin role. Build purpose-built roles narrowed to exactly what the agent needs.
- Require security review before activation. Democratized creation is a feature. Democratized access is a control failure. The review needs to be a deployment gate, not a guideline.
- Audit platform-egress paths as part of identity governance. Salesforce Connect, Cortex’s MCP integrations, Web-to-Lead inputs — these are where in-platform access becomes external exposure. Inventory them.
- Surface in-platform agent activity in identity monitoring, not just the SaaS admin console. Anomalies in query volume, schemas, recipients, or out-of-hours access belong in the same workflows as any privileged identity.
- Apply zero standing privilege to the role behind the agent. A standing, broadly-scoped role is the precondition for every incident in this category. Replace it with permissions minted per request, scoped to the task, revoked when complete.
The control surfaces look different across platforms even when the principle is the same. In Salesforce, the work centers on the permission set scoped to the Agentforce user and the Agent Builder activation gate. In Snowflake, it’s purpose-built roles with row-access and masking policies and a review at Cortex Agent creation. Same principle, different levers.
In a nutshell
There is an instinct, particularly common on teams who came up watching coding agents misbehave, to treat the in-platform agents as the safer cousins. They run inside a vendor’s trust layer, they don’t have shell access, they speak business language. That instinct misreads the threat model. The runtime is the platform. The privilege is whatever the underlying role can do. The blast radius is the data the platform holds. The visibility is whatever your SaaS admin console gives you, which is well short of what your identity monitoring requires. If you would not let a junior contractor query your customer table without scoping, you should not let an agent your sales-ops team built last week do the same. The agents that look like features are the ones already in production.