Top 10 Reasons Agentforce Packages Fail Security Review
Key takeaways:
Most Agentforce security review failures come down to over-permissioned agents, unvalidated inputs, and weak guardrails on autonomous actions, not exotic vulnerabilities.
Salesforce package security now extends beyond code to include prompt handling, session management, and documentation accuracy, since agents act with far more autonomy than traditional packages.
Building with security review requirements in mind from day one is the fastest path to approval on AgentExchange.
If you've built an AI agent package for Salesforce and sent it off for review, you already know the feeling. You wait. You refresh your dashboard. And then the email lands: "Security Review Failed."
Here's the thing: Agentforce security review isn't just another checkbox in the AppExchange publishing process. It's Salesforce's way of making sure that autonomous agents, which can read data, take actions, and make decisions on a customer's org, aren't quietly opening a backdoor somewhere. Given how much access these agents typically need to function, Agentforce security is treated with a level of evaluation that goes well beyond a standard managed package.
So why do so many packages get failed security reviews? Let's walk through the ten most common reasons, so you can fix them before you submit, not after.
10 Reasons Behind Security Review Failure of Agentforce Packages
Here are some of the reasons why Agentforce packages fail security review.
Overly Broad Permission Sets Sink Agentforce Security Review
This is the most common reason packages get rejected. Developers build an agent, give it a permission set with "just in case" access to every object, field, and Apex class in the org, and ship it. Reviewers flag this immediately because it violates the principle of least privilege, a core pillar of Salesforce package security.
An agent that only needs to read Case records and update a Status field shouldn't modify access to Opportunities, Contacts, and User records. Before submission, map out exactly what your agent touches and scope permissions down to that list. Nothing more.
Hardcoded Credentials Are an Instant Red Flag
You'd think this wouldn't need saying in 2026, but hardcoded API keys, session tokens, and connected app secrets still show up in Apex code and Named Credentials configurations all the time. Reviewers actively scan for this, and it's one of the fastest ways to fail any AppExchange security review, agent-based or not.
Use Named Credentials, External Credentials, or Salesforce's secure credential storage instead of embedding anything sensitive directly in code or custom metadata that ships with the package.
Unvalidated Prompt Inputs Open the Door to Injection
This one is fairly new to the review process but growing fast. Agentforce agents that pass user input directly into prompts, tool calls, or Apex actions without sanitization are vulnerable to prompt injection, essentially the AI equivalent of SQL injection. A malicious user could manipulate the agent into executing unintended actions or exposing data it shouldn't.
Reviewers now specifically test for this in Agentforce security review. If your topics, instructions, or actions blindly trust whatever text comes in from a user or an external system, that's a failure waiting to happen. Validate and constrain inputs at every layer where the agent hands off control.
Missing or Weak Data Masking in Sandbox Testing
A lot of teams test their agent packages against sandbox data that's really just a copy of production. Full names, real emails, actual transaction histories. If that data leaks into logs, error messages, or third-party integrations during testing, it becomes a serious Agentforce security issue that reviewers will catch.
Mask or synthesize test data before you ever run your agent through its paces. It's a small step that saves a lot of back-and-forth with the review team.
Agent Actions Aren't Scoped to Object-Level and Field-Level Security
Salesforce enforces Object-Level Security (OLS) and Field-Level Security (FLS) for a reason, and Agentforce agents are not exempt. A common mistake is writing Apex actions or Flow-based actions with “without sharing” or bypassing FLS checks entirely, assuming the agent's permission set will handle it.
It won't, not reliably. Reviewers expect explicit enforcement of sharing rules and field security within every action your agent can invoke. Skipping this is one of the more technical but frequent reasons packages get sent back during Agentforce security review.
Third-Party API Calls Without Proper Governance
Agents that reach out to external services (for enrichment, search, or automation) need complete governance around those calls. That means using approved remote site settings, enforcing HTTPS, validating certificates, and never passing sensitive Salesforce data to an external endpoint without explicit disclosure and consent mechanisms.
This matters even more now that AgentExchange has become the dedicated marketplace for Agentforce-native solutions. Listings on AgentExchange go through even more targeted review of external integrations because these agents are marketed specifically as autonomous, action-taking tools. Not passive apps sitting in the background.
Logging Sensitive Data in Debug Logs or Platform Events
It's easy to forget that debug statements, platform events, and even custom logging objects can capture more than you intended, like PII, session details, or business-sensitive data that then sits around indefinitely. When an AI agent is making decisions and taking actions at speed, it tends to generate a lot more log volume than a traditional package, which means more opportunities for sensitive data to end up somewhere it shouldn't.
Audit every log statement your package writes. If it captures anything identifiable, either redact it or don't log it at all.
Insufficient Guardrails on Autonomous Actions
This is fairly specific to Salesforce Agentforce AI and doesn't apply to traditional packages in the same way. Reviewers now look closely at whether an agent has appropriate guardrails before taking consequential actions like sending emails, updating records in bulk, triggering downstream automations, or interacting with financial data.
If your agent can autonomously execute a high-impact action without any confirmation step, approval workflow, or rate limiting, expect pushback. Build in checkpoints. Even a lightweight human-in-the-loop confirmation for sensitive actions goes a long way toward passing review.
Poor Session and Token Management for Agent-to-Agent Communication
As agents increasingly talk to other agents and external tools, session handling becomes a real attack surface. Packages that reuse tokens across sessions, fail to expire credentials properly, or don't isolate one customer's agent session from another's are a serious Salesforce package security concern.
Each agent interaction should have properly scoped, short-lived tokens, and there should be no cross-tenant leakage possible, even in theory. Reviewers will test this with multiple test org configurations, so don't assume it'll slip through.
Incomplete or Inaccurate Security Documentation
Sometimes the technical implementation is fine, but the package still fails because the documentation submitted alongside it doesn't match what the code actually does. Reviewers cross-reference your security questionnaire responses against the actual permission sets, API calls, and data flows in the package. Any mismatch triggers a fail or, at minimum, a lengthy round of clarification requests.
Take the documentation seriously. List every object accessed, every external endpoint called, and every permission requested, and make sure it lines up exactly with what the Agentforce reviewers will find when they open the package.
How to Actually Pass Agentforce Security Review
Knowing the failure points matters, but building with review requirements in mind from day one matters more. Treating security as a final step before submission is where most of these issues start. A few practices that consistently help:
Run a self-assessment against Salesforce's published security review checklist before you ever submit.
Use static analysis tools like Salesforce Code Analyzer early and often, not just before submission.
Treat every agent action as if it could be misused, and design guardrails accordingly.
Keep documentation as a living artifact that's updated alongside the code, not written after the fact.
If your internal team is newer to building for Agentforce, it's worth bringing in expertise rather than learning these lessons the hard way. Teams that hire AppExchange developers with prior security review experience tend to move through the process faster, simply because those developers have already seen most of these failure patterns firsthand and know how reviewers think.
This is especially useful now that AgentExchange has raised the bar for what a "secure" agent package looks like, and developers who specialize in Agentforce builds tend to stay updated with review criteria as it evolves. Something that's harder to do if you're only submitting a package once every year or two.
Final Thoughts
Failing an Agentforce security review isn't the end of the world. Most teams go through at least one round of revisions before getting approved. But understanding why packages fail before you submit saves weeks of back-and-forth and gets your agent into customers' hands faster.
Agentforce security isn't just Salesforce being cautious for the sake of it. These agents can act autonomously inside a customer's most sensitive business data, and the review process exists to make sure that trust isn't misplaced. Build with that trust in mind from the start, and the review process becomes a formality rather than an obstacle.
Would you like to streamline your Agentforce security review? Get the help of experienced AppExchange developers at Concretio to ensure your package is audit-ready and build with confidence.
Frequently Asked Questions
-
Timelines vary, but most Agentforce security review submissions take anywhere from a few days to several weeks, depending on package complexity and how many revision cycles are needed. Packages with autonomous actions or third-party integrations tend to take longer due to the added scrutiny.
-
A standard AppExchange security review focuses on things like code quality, data access, and standard integration security. Agentforce security review includes all of that plus agent-specific checks since these packages can act on their own rather than just respond to user input.
-
Yes. Most teams don't pass on the first try. Salesforce provides feedback on what failed, and you can fix the flagged issues and resubmit. Keeping detailed notes on reviewer feedback also helps avoid repeating the same mistakes in future submissions.
-
AgentExchange listings go through the same core Salesforce security review process, but with additional focus on agent autonomy, action guardrails, and external API governance, since these packages are built specifically around Agentforce's AI capabilities.
-
If your team is new to building for Salesforce Agentforce AI, it can save significant time. Teams that hire AppExchange developers with prior review experience typically move through the process faster because they already know common failure points and how reviewers evaluate submissions.
Related Readings
Let’s Talk
Drop us a note, we’re happy to take the conversation forward 👇🏻
