Cloud transformation did not simplify security. It distributed it.
Infrastructure, applications, and data now operate across distinct layers, each with its own controls, owners, and failure points. Salesforce sits squarely in the middle of that complexity. It depends on cloud infrastructure, yet its risks are driven by how the application is configured, accessed, and extended.
To manage this, organizations turned to posture management. CSPM and SSPM emerged to bring discipline to different parts of the stack. But they are often misunderstood, deployed in isolation, or treated as interchangeable.
That assumption is where risk begins.
We’ll explore these 7 factors of both CSPM security and SSPM security:
- AI Agents Don’t Just Read Data. They Act on It.
- Over-Permissioned AI Turns Small Mistakes Into Big Problems
- Prompt Injection Is a Real Security Problem
- Static Code Analysis Still Matters
- Data Classification Defines What AI Should Know
- Shadow AI and Weak Governance Are Already Creating Risk
- Monitoring Has to Be Active, Not Passive
1. AI Agents Don’t Just Read Data. They Act on It.
The first mistake is treating AI agents like chatbots. A chatbot may answer a question. An agent can complete a task.
That distinction changes the risk model. Agentforce may connect to CRM records, Apex code, flows, APIs, approval processes, knowledge articles, and third-party systems. If access is too broad, the agent may expose sensitive data, update the wrong record, trigger the wrong workflow, or cause downstream business disruption.
This is why least privilege must be a design requirement. Salesforce emphasizes secure Agentforce practices such as least privilege, secure actions, testing, and monitoring. Those controls are not administrative details. They define the boundary between useful and uncontrolled automation.
A secure agent should have only the access required for its intended purpose. Not broad object access because it is easier. Not elevated permissions because the pilot needs speed. Not unrestricted action rights because “we’ll fix it later.”
2. Over-Permissioned AI Turns Small Mistakes Into Big Problems
AI tools fail differently than traditional software. A conventional workflow follows a predictable path. An AI agent interprets intent, retrieves context, and may choose between possible actions.
That flexibility is useful, but it also increases the blast radius of weak permissions.
OWASP identifies “excessive agency” as a major LLM application risk, driven by excessive functionality, permissions, or autonomy. In practice, this means an agent with too much authority can be manipulated into doing things it should never be able to do.
The answer is not to avoid AI. The answer is to constrain it. Separate read access from write access. Limit actions by role, use case, and data sensitivity. Require human approval for high-impact operations. Apply object-level and field-level controls with precision.
An agent that summarizes an opportunity does not need permission to change ownership. An agent that supports case triage does not need access to every customer record. An agent that recommends next steps should not execute them without appropriate checks.
3. Prompt Injection Is a Real Security Problem
AI agents process instructions from multiple sources. Some come from trusted users. Others may come from records, documents, emails, websites, or connected systems. Attackers can hide malicious instructions inside those inputs to redirect the agent’s behavior.
That is prompt injection, and it is one of the clearest reasons AI security needs its own controls.
Recent examples show how real this threat has become. The Guardian reported that hackers exploited Meta’s AI-powered support bot to gain unauthorized access to high-profile Instagram accounts by manipulating account recovery workflows. Security researchers also documented EchoLeak, a Microsoft 365 Copilot vulnerability showing how a crafted email could enable zero-click data exfiltration from an AI system.
The lesson is straightforward: any AI agent connected to sensitive systems must assume hostile inputs exist. Guardrails help, but they are not enough. Organizations need permission boundaries, secure retrieval, input validation, output filtering, approval gates, logging, and continuous testing.
4. Static Code Analysis Still Matters
AI can amplify code risk.
Agentforce may interact with Apex, Lightning components, flows, APIs, custom integrations, and automation logic already embedded across Salesforce. If that underlying code contains vulnerabilities, hard-coded secrets, insecure sharing assumptions, weak validation, or brittle logic, the agent can expand the impact.
Static code analysis gives teams a way to find issues before they reach production. It helps identify security flaws, quality problems, compliance gaps, and policy violations across Salesforce development.
The issue is with malicious code and fragile code. An agent may call an action exactly as designed, but if the action itself is unsafe, the outcome is still unsafe. Secure AI depends on secure foundations.
That means scanning Apex and related components, enforcing development standards, validating changes before release, and reviewing every agent-accessible function for security and business impact.
5. Data Classification Defines What AI Should Know
AI agents are only as safe as the data boundaries around them. If sensitive data is not classified, protected, and governed, the agent has no reliable way to know what should be restricted.
This is especially important in Salesforce, where sensitive information often lives across standard objects, custom objects, free-text fields, attachments, case notes, knowledge content, and integrated systems. Customer data, employee data, financial data, contracts, credentials, and regulated business records may all exist in the same environment.
Data classification gives teams a shared map of risk. It helps determine which fields can be used in AI responses, which should be masked, which require approval, and which should be excluded from agent workflows entirely.
Without classification, organizations rely on assumptions. That is not governance. That is exposure with a cleaner interface.
6. Shadow AI and Weak Governance Are Already Creating Risk
AI adoption is moving faster than AI governance. Teams want productivity. Developers want speed. Business units want automation. But when AI tools are introduced without visibility, access controls, testing, and policy enforcement, organizations create a parallel technology layer outside normal security oversight.
Agentforce should not become another shadow AI surface. It should be governed as part of the Salesforce lifecycle, with clear ownership, documented use cases, approved data access, secure development practices, monitored behavior, and regular reviews.
7. Monitoring Has to Be Active, Not Passive
AI security does not end when the agent goes live. In many ways, that is when the real work starts.
Agents operate in changing environments. Data changes. Users change. Prompts change. Integrations change. Permissions drift. A safe configuration today can become risky tomorrow.
Organizations need visibility into what agents access, which actions they trigger, who invokes them, and where exceptions occur. Monitoring should detect unusual behavior, excessive access patterns, failed guardrail events, unexpected outputs, and risky action attempts.
This is not about slowing AI down. It is about making AI accountable.
Secure AI Is the Only AI That Scales
Agentforce can create meaningful value, but only if trust scales with adoption. The organizations that succeed with AI will not be the ones that move fastest without control. They will be the ones that build security into the foundation.
That starts with least privilege. It includes static code analysis, data classification, secure release management, prompt injection defenses, human oversight, and continuous monitoring.
AI security cannot be an afterthought because AI agents do not sit at the edge of the enterprise. They operate inside the systems where customers, revenue, operations, and risk already live.
The question is not whether AI tools need protection. The question is whether the organization is prepared to protect everything those tools can now reach.