Salesforce Agentforce Highlights the Limits of Paper AI Governance
Researchers documented how standard Salesforce features can create an external path into an Agentforce agent: public internet, email, case record, Flow, agent prompt, agent action, case comment and outbound reply. Email-to-Case and Web-to-Case convert inbound customer messages into case records, while Flow can pass record data into an agent prompt.
The sequence does not depend on a misconfiguration or an exploit. It illustrates a governance problem created when an agent is introduced into an established application whose intake routes, records, automations and permissions were designed long before the agent existed.
Risk sits in the surrounding application
An unauthenticated sender may reach an internal agent’s instructions when inbound email becomes a case and an automation supplies that case data to the prompt. The eventual reply can leave through the same support channel. Whether this amounts to a support-queue problem or a data-exposure risk depends on the configuration around the agent.
The relevant questions include which intake features are enabled, which triggers run, which objects are available to guest users, which automations pass untrusted data onward and which underlying model version the agent calls. A vendor assessment performed during procurement may not capture those conditions if the agent was deployed later.
Prompt filtering also has a limited view of this path. A filter can inspect agent input but does not inherently understand that a particular value originated with an unauthenticated sender through Email-to-Case. Securing such an agent requires knowledge of the host application at the depth available to its administrators.
Inherited platforms make agents harder to govern
The article places the issue alongside the City-Forum campaign, an active data-theft operation targeting Salesforce and ServiceNow instances since March 2025. The campaign was identified in the gap between platform capabilities and the configurations enterprises operate in practice.
Agent creation is also becoming available to business teams outside central engineering. Marketing operations may build an agent to retrieve pipeline reports, while finance may build one to reconcile invoices. These agents use their creators’ permissions, which makes them useful but also extends unattended access across privileges accumulated over time.
The OWASP Agentic Skills Top 10 identifies a related governance weakness: a skill deployed and managed inside a third-party platform may be unreachable to external scanners. A policy or committee cannot answer the operational questions of how many agents are active, what they can access and who owns them unless the organisation can first discover them.
Build governance from visibility upward
The proposed operating order begins with continuously refreshed discovery across application configurations, OAuth grants, network, endpoint, email metadata and browsers. It then moves through platform posture, an identity and named owner for every agent, visibility into usage, least-privilege controls, approval or quarantine for new agents and live runtime inspection.
Each layer supports the next. Teams should be able to name the intake features and guest-user exposures connected to agent triggers on major platforms, and a randomly selected agent should have a human owner who can be identified promptly. Runtime enforcement deployed before that inventory and context risks operating without the information needed to make sound decisions.
The business implication is practical: treat agent governance as an operational record of inventory, ownership, configuration and review history, then use that record to assess each agent’s full exposure before relying on policy documents or runtime controls alone.