Skip to main content

Vulkro for Salesforce

Your org has AI agents now. Review them like code.

Salesforce orgs are now partly written by AI too: Agentforce agents acting on records, generated Apex, Flows prompted into existence. The security review has not kept pace, and the first Agentforce breach has already happened. Vulkro for Salesforce reviews your code, metadata, and org settings on your machine, in the language the AppExchange security reviewer uses, and nothing about your org is uploaded anywhere.

Start the 14-day trialAppExchange readiness docs →
  • Scans run locally
  • Nothing uploaded
  • No AI in the scan
  • Reads zero customer records
  • 14-day full trial
$ vulkro-sf scan ./force-app
[HIGH] AS-003: agent grounding reads an untrusted
       free-text field (Case.Description) with no
       sanitization marker.
       in support_agent.agent : the ForcedLeak
       injection vector
Runs on your machine. Reads zero customer records.

Nine areas of risk, dozens of checks each. One command runs all of them on your machine. Pick yours to jump to the detail.

The new surface

Agentforce is an attack surface. Almost nobody reviews it.

An AI agent in your org reads record fields, grounds on your data, and calls your Apex. Attacker text planted in a Description field becomes an instruction; an action bound to a without-sharing class becomes a data leak. ForcedLeak proved the class is real. Vulkro ships 15+ detectors for exactly this surface, and reviews both the compiled agent metadata your org runs and the Agent Script source you author.

The ForcedLeak pack

Detectors built from the Noma research that produced the first published Agentforce vulnerability class (rated CVSS 9.4): agent actions bound to Apex that runs without a sharing check, grounding on PII-bearing free-text fields an outsider can write to, and unscoped retrieval an agent can steer to records it should never see.

$ vulkro-sf scan . (rules AP-061..AP-070)

Compiled agent metadata

Reads the agent metadata your org actually runs: bots, planners, prompt templates, and GenAiFunction actions. Fires when an action whose target is Apex points at a class declared without sharing, when an agent-reachable class opts into system-mode data access, and when a grounded prompt template has no allowlist or filter.

$ vulkro-sf scan ./force-app

Agent Script source

The same review for the authoring source that compiles to that metadata: five rules (AS-000 to AS-004) covering actions bound to without-sharing classes, bundles with no least-privilege runAs guard, grounding on untrusted free-text fields, and over-broad action scopes. Ships before your CI compiles the bundle, so the flaw never reaches the org.

$ vulkro-sf scan . (rules AS-000..AS-004)

New in SF v0.5.0

Live-org AI inventory

Inventories the AI surface of a live org through definition objects only: agents, topics, actions with their invocation targets, prompt templates, and the org-level Einstein generative-AI enablement flags. Each probe reports honestly as detected, empty, or unavailable. The OAuth token stays inside your own sf CLI throughout, and zero customer records are read.

$ vulkro-sf serve (Org, Agentforce inventory)

New in SF v0.5.0

AI-origin audit

Reports which findings landed on AI-authored Apex, LWC, and Aura files, broken down per tool, plus the AI-touched file list. Detection is marker-based only: an explicit tool marker in a comment counts, code style is never guessed, so an unmarked file is a safe miss rather than a false claim.

$ vulkro-sf scan --ai-code-segregation ./force-app

A knowledge bundle that keeps up

The Agentforce field and pattern catalog ships as a signed remote bundle, refreshed without a binary release, so new agent attack patterns land as data. Air-gapped runners set one environment variable and use the bundled-in seed catalog with zero outbound calls.

$ VULKRO_SF_OFFLINE=1 vulkro-sf scan .

The flagship report

Know the Security Review verdict before you pay for one.

The AppExchange Security Review readiness report rolls every finding up into the published Partner Security Review requirement categories and gives one verdict: READY or GAPS. CRUD and FLS gaps and sharing mistakes, among the top reasons a review is rejected, are exactly what the underlying detectors target.

The readiness verdict

Six requirement categories, each scored pass, gap, or not-evaluated, and one overall verdict. The release manager's view before clicking submit. A category with no detector coverage says not-evaluated and tells you to verify it manually; it never silently passes.

$ vulkro-sf asrr . --format markdown

The engineer's gate

Ten named go / no-go gates (secrets, CRUD/FLS, injection, sharing, cleartext endpoints, cryptography, Lightning, Visualforce, metadata, Flow) as a pass / fail table for CI. Exit code 0 when every gate passes, 1 when one fails, so the pipeline blocks a doomed submission automatically.

$ vulkro-sf presubmit . --format json

The file you hand off

The full report as one HTML file, grouped by the same checklist your AppExchange reviewer uses. Section by section, what cleared and what still needs work. Open it in a browser, save as PDF, attach it to the submission or hand it to a client.

$ vulkro-sf appexchange-report -o readiness.html

A failed Security Review costs the per-submission fee Salesforce charges, the resubmission queue, and the release you had planned around it. Finding the blockers on your own machine first is the cheap path.

How it finds real risks

It follows your data across Apex, then tells you if it is safe.

A pattern scanner flags anything that looks like a database call and buries you in false alarms. Vulkro follows the actual path a piece of untrusted input takes through your Apex, and only raises an alarm when it reaches something dangerous with no access check in between. Fewer false alarms, and the serious risks caught.

SafeA user typed value→an Apex controller→a CRUD and FLS check→a SOQL queryNo alarm. The access check is there.
RiskA user typed value→an Apex controller→no access check→a SOQL queryAlarm. A user can read records they should not.

Same input. The only difference is whether an access check sits in the path, and that is exactly what Vulkro follows. The same follow-the-data engine reviews the path from an AI agent action into your Apex.

The same approach powers the Apex, Lightning, Flow, and access checks below. Same code, same result, every time. No AI in detection, no guessing.

The depth

Built for the checks a reviewer actually rejects on.

CRUD and FLS gaps and sharing mistakes are among the top reasons an AppExchange Security Review is rejected, and Vulkro for Salesforce targets them directly.

109

Salesforce detector modules

70+

Well-Architected anti-pattern rules

15+

Agentforce and AI-agent detectors

Interprocedural Apex taint

Untrusted input followed from source to sink across files, not just the line it appears on, so a risk that spans several classes is still caught.

LWC-to-Apex cross-language bridge

A value that starts in a Lightning Web Component and flows into Apex is tracked across the language boundary, so a browser-side input that reaches a server-side sink does not slip through.

A live-org audit that stays hands-off

The live-org audit reads your settings through your own sf CLI login. It never holds the OAuth token and reads zero customer records: definition objects and settings metadata only, never Accounts, Cases, or any other row of your business data.

$ vulkro-sf org perms (token stays in your sf CLI)

Group 01 / Your code

The code your team wrote.

The flaws in your own Apex, Lightning, and Flows are the ones a reviewer rejects and an attacker hits first.

Apex code

The custom logic behind your org, checked for the flaws that fail a review: places a user can reach records they should not, places their input steers a database query, and missing access checks. Followed across files, not just the line it appears on.

Lightning: LWC and Aura

Your Lightning Web Components and Aura components, checked for the scripting flaws that let a page render something a user should never control, and for customer data left exposed in the browser.

Flows

Screen and autolaunched flows, checked for the same access and exposure gaps as code, including flows that a guest visitor can reach without signing in.

Group 02 / Access, configuration, and secrets

Who can reach what, and how the org is set up.

Most Salesforce incidents were not code bugs. They were an over-broad profile, a connected app with the wrong scope, or a setting nobody wrote down. Vulkro reviews all of it.

Access and sharing

Profiles, permission sets, and sharing rules that hand out more than the job needs, and the guest-user access that turned a public site into a data leak at other companies.

Org configuration

The org-wide settings a reviewer checks: cross-origin rules, content-security policy, remote site access, and session hardening. What cleared and what did not, written down instead of left to memory.

Secrets and credentials

Named credentials, API keys hardcoded into your source, and secrets left behind in your git history. What should never be in the code, found before it ships.

Data exposure

Where personal data ends up somewhere it should not: a debug log, an error message, a place a user can see. A privacy slip caught before a customer finds it.

All of this runs on your machine. Vulkro for Salesforce reads your code and settings only, and never reads your customer data.

The proof

Built from the breaches that actually hit Salesforce.

Each check maps to the weak spot behind a real, published Salesforce incident. You are catching the patterns that already cost other teams real customers.

ForcedLeak, the first Agentforce breach

An AI agent could be steered by attacker text planted in a record field, and the code it triggered ran without a sharing check (rated CVSS 9.4 in the Noma research). Vulkro catches the class bypass, the untrusted grounding field, and the agent action that exposes them.

Drift OAuth token theft

One of the 2025 Salesforce supply-chain breaches driven by stolen OAuth tokens: a third-party assistant lost its tokens and attackers replayed them straight into customer orgs. Vulkro catches the over-permissioned connected app that turns a vendor slip into your incident.

Gainsight OAuth abuse

Same vector, same year, a different vendor. The same check catches it, because the underlying misconfiguration is the same. Vendor names change; the weak spot does not.

Experience Cloud guest user exposure

A guest-user profile that could read standard objects it should never have seen. Vulkro flags the profile setting that makes the exposure possible.

ShinyHunters vishing campaigns

Records lifted after attackers talked someone into approving a connected app with the wrong scope. Vulkro flags the connected-app setting that makes the call worth making.

Reviewer-aligned. Reads zero customer records. Runs on your machine. Licensed the same way as the core scanner: per seat, directly through our team.

Reviewer-aligned report
Reads zero customer records
Runs on your machine, nothing uploaded
No AI in detection: same code, same result
See the full detector list →How licensing works →

Not just Salesforce

The same offline engine scans your other code.

Your services outside Salesforce have their own risks: broken access, injected input, leaked keys, risky dependencies, and the new risks your AI coding tools bring in. Those ship in the core Vulkro scanner, built on the same offline engine, so nothing you run ever leaves your machine.

See what the core scanner checks →Talk to us →

What the core scanner covers

Your application

Secrets and personal data

Dependencies and supply chain

AI development surface

Infrastructure

What it does not do

Where this edition is the wrong tool, we say so.

Your customer records
Vulkro for Salesforce never reads them. No Accounts, Opportunities, Leads, Cases, custom-object rows, or attachments. The live-org audit reads definition objects and settings through your own sf CLI login; the OAuth token stays inside that CLI and is never held by Vulkro.
What the static scan cannot see
A source scan reviews the code and metadata in your repo. It cannot see what changed in the org after deployment: a permission set edited in Setup, a connected app approved yesterday, a session policy relaxed by an admin. That is what the live-org audit is for; run both.
What the live-org audit cannot see
The live-org audit reads settings and definitions, not code paths. It cannot follow tainted input through your Apex or tell you a SOQL query is injectable; that depth needs the source scan. The two halves are different views of the same org, not substitutes.
Checks it cannot evaluate
A readiness category with no detector coverage on a given scan is reported as not-evaluated, and does not silently pass. The report tells you to verify it manually rather than pretending it cleared.
AI-written code detection
The AI-origin audit is marker-based only: it counts a file as AI-authored when a comment carries an explicit tool marker. It never guesses from code style, so unmarked AI code is a safe miss, not a false claim.
Anything outside Salesforce
This edition is Salesforce-only. For your other services and their code, use the core Vulkro scanner.
A live penetration test
This is a review of your code and settings, not an attack against a running org. It finds the weak spot; it does not exploit it.

If it is not on this page, assume this edition does not check it yet, and tell us what you need. Covers Agentforce and Agent Script, Apex, Lightning (LWC and Aura), Flow, Visualforce, and your org configuration.