In July 2025, security researchers at Noma Security disclosed a vulnerability in Salesforce Agentforce, later cataloged with a near-maximum severity score of 9.4 out of 10. The mechanism was almost mundane: a hidden instruction embedded in a Web-to-Lead form caused a customer service agent to exfiltrate CRM data, sales pipeline details, and integration credentials. No exploit was needed. No policy was violated. The agent did exactly what it was authorized to do, just pointed somewhere no human intended.
That’s the part worth sitting with. This wasn’t a case of an agent breaking the rules. It was a case of the rules being too generous in the first place. Almost every AI agent security incident, in Salesforce and everywhere else, follows the same shape: an agent inherits more access than the task actually requires, and eventually something, a prompt, a malformed input, a chained request, uses that access in a way nobody planned for.
This is why least privilege, a decades-old security principle, has suddenly become the central conversation in agentic AI governance. Here’s what it means in practice for a Salesforce org, why the platform’s own defaults work against it, and how to fix it without slowing your team down.
Least Privilege, Defined for Agents Specifically
The principle itself is old and simple: give any identity, human or otherwise, only the access it needs to complete its task, and nothing it accumulates along the way.
Applying it to AI agents is where it gets harder than it sounds. A human user’s access is relatively static, set once via profile and permission sets, reviewed occasionally. An AI agent’s access needs are dynamic: it might need broad read access to research a question, narrow write access to execute one specific action, and no access at all to everything else, all within the same conversation. Static, profile-based access control was never designed for that kind of task-by-task variability, which is exactly why organizations are struggling to apply an old model to a genuinely new problem.
The industry has started calling out a related idea worth knowing: OWASP’s Top 10 for Agentic Applications now defines "least agency" as the agentic equivalent of least privilege, meaning minimum autonomy, minimum tool access, and minimum credential scope, treated as a design requirement rather than something reviewed after the fact.
Why This Matters More in Salesforce Specifically
A few things about how AI agents operate inside Salesforce make this a sharper problem than it is in a generic enterprise app.
Agents can inherit more than the requesting user has. According to security research from Obsidian Security, Agentforce agents can run Flows and execute Apex in system mode, which grants effectively admin-level data access regardless of the role of the user who invoked the agent. That’s a meaningful departure from the assumption most admins carry into AI adoption, which is that an agent’s access is simply a mirror of the user talking to it.
Access accumulates through convenience, not malice. A narrow agent built for one lookup gets reused for a new use case, picks up a broader action, and within a few iterations has read access across a large share of the CRM, all without a formal access review. Security teams investigating these incidents consistently find the same root cause: not bad actors, but a combination of permissive platform defaults, builder convenience, and pressure to ship fast.
Orphaned agents keep running after their creator leaves. When an agent is built under a specific person’s credentials, sometimes called maker mode, it continues operating with that person’s original privilege level even after their account is disabled. There’s no active owner left to catch the drift, and no automatic downgrade when the human behind the agent leaves the company.
The scale of the problem is bigger than most admins expect. Independent research now puts the average ratio of machine identities to human identities above 80 to 1 in cloud-native environments, and one recent industry report found that the large majority of non-human identities in a typical enterprise carry more privilege than their actual function requires. Salesforce orgs, with agents now embedded directly into CRM workflows, are not exempt from that pattern.
What Good Looks Like: Five Practical Controls
None of this requires abandoning Agentforce or any other agent platform. It requires treating agent access with the same rigor you’d apply to a new integration user, and then going further, because agents behave differently from static integrations.
1. Scope by task, not by role. Instead of assigning an agent a broad permission set "so it can do its job," define the specific objects, fields, and actions each task actually requires, and grant only that. If an agent needs to update Opportunity stage, it doesn’t need edit access to Contacts.
2. Use time-limited access for anything elevated. Just-in-time permissions that expire beat standing access every time. Temporary access without an expiry mechanism becomes permanent access in practice, which is precisely the pattern behind most of the orphaned-agent incidents security teams report.
3. Re-check authorization at every downstream step, not just at the entry point. An agent that’s authorized to start a workflow isn’t automatically authorized for every action inside it. Logging only the initial request creates an audit trail that looks complete but is useless for actually reconstructing what happened.
4. Name an owner for every agent, and revoke access the moment that owner leaves. This closes the maker-mode gap directly. An agent without a living, accountable owner is a liability whether or not it’s ever misused.
5. Review MCP and connector access as its own category, separate from user permissions. Any MCP server or external tool an agent can call is a separate inventory item with its own blast radius. A misconfigured or overly permissive MCP connection can expand an agent’s effective access well beyond what the underlying user could do on their own, which is exactly the gap a strong least-privilege review needs to catch.
Where This Connects to How Cirra AI Is Built
This is worth being precise about, because the distinction matters more here than almost anywhere else in Salesforce AI tooling.
Cirra AI connects to Salesforce over OAuth and executes strictly within the authenticated user’s existing permissions and field-level security. It cannot do anything that user couldn’t already do by hand in Salesforce, because there’s no separate elevated execution mode: the access is the user’s access, full stop. That’s a structurally different model from an agent running in system mode, where the agent’s effective permissions can exceed the permissions of the person who triggered it.
Two capabilities in Cirra AI’s metadata layer map directly onto the audit work described above. You can ask it to check access for a specific object or field, who can see this and through what permission set or profile, on demand, rather than reconstructing that answer manually across Setup screens. And because every change it makes is documented as it happens, you get the kind of granular audit trail that a system-mode agent, logging only its final output, typically can’t provide.
This doesn’t mean Cirra AI replaces a proper least-privilege review of your agent stack. It means that when you’re evaluating which parts of your AI tooling need the closest scrutiny, a tool whose access model is inherited permissions with nothing else layered on top is a meaningfully smaller attack surface to reason about than one running with its own elevated execution context.
The Takeaway
The Agentforce disclosure wasn’t an edge case. It was a demonstration of what happens by default when agent access is granted for convenience rather than scoped to task. The fix isn’t more monitoring after the fact, it’s tighter scoping before the agent runs: task-based access, time-limited elevation, per-step re-authorization, named ownership, and a separate inventory for every connector and MCP server in the mix.
If part of your AI governance review includes deciding which tools touch your Salesforce metadata directly, it’s worth understanding exactly what access model each one runs on before you connect it. See how Cirra AI’s permission model works, or start a free trial to see what it can, and deliberately cannot, do in your org.
