Salesforce Red Team Agent: native penetration testing is coming. What to do until it arrives

At the Dreamforce 2026 security keynote, Pete Thurston, Salesforce's VP of product management for trusted services, announced a Red Team Agent for Security Center: an AI agent built to break into your Salesforce org the way a real attacker would, then tell you how it got in.

It is one of the more useful things announced this year, because it fills a real gap. Today there is no native way to penetration test a Salesforce org. You hire a firm or buy a third-party tool, and most small teams do neither.

This post covers what Salesforce has said, what it has not, and how to get most of the value now, before the agent ships.

What the Red Team Agent is

Based on Salesforce Ben's report of the keynote (2 October 2026):

• It attacks, rather than inspects. Health Check and Security Center tell you a setting is weaker than a baseline. The Red Team Agent tries to exploit what it finds and shows you the path it took. Salesforce Ben compared the difference to a building inspector versus a friendly burglar.
• It has three stated goals: find issues you had not thought to look for, prove a vulnerability is real rather than theoretical, and help you prioritise fixes before an outsider finds them.
• Salesforce built it for itself first. Salesforce's own penetration testing team built the agent and has used it to cover far more of Salesforce's footprint than people alone could.
• It will live in Security Center.

It was announced alongside MCP Risk Scores, which scan MCP servers when they are registered with Agentforce and continuously afterwards, rating each Low, Medium or High (Salesforce IT announcements). Both reflect the same worry: more agents, more integrations, more doors.

What we do not know yet

As of 14 October 2026, Salesforce has published no documentation for the Red Team Agent. Specifically, there is:

• No release date. "Coming soon" is the only timing given.
• No price. It is not confirmed whether it will be part of the free Security Center Essentials or the paid Security Center product.
• No stated scope. The keynote did not say whether it tests social engineering such as phishing or vishing, which an automated agent would find hard to do responsibly.

So budget for it as unknown. Do not cancel an external test on the strength of a keynote.

Can you pen test your Salesforce org today?

Yes, and you no longer need to ask first. Salesforce's Knowledge article Salesforce Security Assessments (000394469) says that since 31 January 2023 customers do not need prior approval to run security assessments of Salesforce products. Testing must still follow the Security Assessment Agreement.

Salesforce's responsible disclosure policy adds the ground rules any tester, human or AI, should follow:

• Test against a trial, Developer Edition or sandbox wherever one is available, and with test accounts.
• No denial of service, brute force or spam.
• Do not access, change or destroy data that is not yours.
• No social engineering of Salesforce staff or service desks.

If a test produces findings, Salesforce asks you to validate automated results first (it publishes common false positives) and submit confirmed ones through security.salesforce.com/contact. Questionnaires and due-diligence requests go through your account executive, not the security inbox.

What a Salesforce pen test usually finds

Most real-world Salesforce exposures are configuration, not platform bugs. Under the shared responsibility model Salesforce restated at the keynote, Salesforce secures the platform and you own the configuration, users, processes and agents. That is where testers look:

1. Guest and Experience Cloud access. Guest user profiles with read access to objects that hold real data, and sharing rules that open records to unauthenticated visitors. This is the classic "public site leaks records" finding.
2. Apex that ignores sharing and field-level security. Classes declared without sharing, @AuraEnabled methods that return whole records, and dynamic SOQL built from user input.
3. Over-privileged integration users. API-only users with Modify All Data "because it was easier", and connected apps whose tokens never expire.
4. Secrets in the wrong place. API keys in custom settings, custom metadata or Apex string literals that any developer, or any agent reading the code, can see.
5. Dormant accounts with power. Ex-staff or old contractor accounts that are inactive but still hold View All Data or Manage Users.
6. Weak session and login settings. No MFA enforcement for some users, wide login IP ranges, long session timeouts.

An attacker, or a red team agent, chains these together: a guest user reaches an @AuraEnabled method that runs without sharing and returns records it should not.

A practical plan until the Red Team Agent ships

1. Turn on Security Center Essentials. It is free, gives you a Health Check score against Salesforce's baseline, and needs only the View Security Center Pages permission. If the Red Team Agent lands there, you will be ready.

2. Run a configuration audit you can repeat. A pen test is a snapshot. Configuration drifts weekly. A repeatable audit catches the drift between tests.

3. Fix the findings that need no attacker to prove. Dormant privileged accounts, guest access to real objects and without sharing Apex behind public pages are worth fixing on sight.

4. Commission an external test for anything public-facing. Experience Cloud sites, public APIs and Sites pages are where a human tester, or eventually the agent, earns its keep. Point them at a full sandbox that mirrors production.

5. Re-test after big changes. New site, new integration, new agent connected over MCP: each one is a new door.

Where orgadmin.ai fits

orgadmin.ai's Security Review is the inspector half of the job, run as often as you like. Fourteen modules cover privileged access, sharing, object and field-level security, guest and external access, Apex security, integrations, files and data egress, and more. Every finding carries its evidence, and the checks are curated from a professional Salesforce security audit.

It does not try to break in. It tells you where an attacker would start, so the external test (or the Red Team Agent, when it ships) spends its time on what is left. Pair it with:

• User Management, which flags dormant accounts that still hold Modify All Data, View All Data or Manage Users, and lists failed logins by reason.
• The Permissions Workbench, to see exactly who can do what and through which permission set.

Summary

• The Red Team Agent is an AI attacker for your own org, coming to Security Center. No date, no price, no published scope yet.
• You can pen test your org now without approval, within the Security Assessment Agreement and Salesforce's testing rules.
• Most findings are configuration. Fix guest access, Apex sharing, privileged dormant accounts and exposed secrets first.
• Audit often, attack occasionally. Use a repeatable audit between tests, and use the agent or an external tester for proof.

Last checked 14 October 2026. We will update this post when Salesforce publishes Red Team Agent documentation or pricing.