Live-org verification

The vulkro-sf org commands read a live Salesforce org through your own sf CLI login. This page is the procedure to verify the connector works end to end against your org. Run it once after install to confirm the handoff, then again whenever you add a new org alias.

What the connector reads, and never reads

This is the single most important thing to understand before you connect an org:

• Reads (metadata only): Profiles, Permission Sets, SecuritySettings, Sharing Rules, Connected Apps, Named Credentials, Flow definitions, GenAiFunction declarations, Static Resources, installed packages. This is the same surface a Salesforce admin sees in Setup.
• Never reads: customer records. No Accounts, Opportunities, Leads, Cases, Contacts, custom-object rows, file attachments, or any business data. No SOQL SELECT against your data. The connector uses the Metadata API and the Tooling API only.
• OAuth token: stays in the official sf CLI credential store on your laptop. Vulkro asks the CLI to perform the metadata fetch; the CLI returns the response. Vulkro never sees the token, never stores it, never transmits it.

Step 1: Install the Salesforce CLI

The org subcommands shell out to sf. Install it once:

# macOS:
brew install salesforce-cli

# Linux / Windows / macOS (npm):
npm install -g @salesforce/cli

Confirm it is on your PATH:

sf --version

Step 2: Authenticate your org

Log in to the org you want to scan and give it a memorable alias:

sf org login web --alias my-prod

A browser window opens for the standard Salesforce login. After you approve, the sf CLI stores the OAuth token in its own credential store. Confirm the alias is registered:

sf org list

You should see my-prod in the list with a Connected status.

Step 3: Verify connectivity

vulkro-sf org status --target-org my-prod

Expected output: the org identity (org id, instance URL, my-domain, edition, and whether it is a sandbox or production org). If this prints the org identity, the handoff works and you are ready for the posture commands.

Step 4: Read identity posture

vulkro-sf org perms --target-org my-prod

This audits Profiles and Permission Sets for over-privilege, flags dormant privileged accounts (ghost admins), and reports guest-user-license elevations (the Experience Cloud breach class). A finding looks like:

[High] Permission Set `Custom_Admin_Access` grants Modify All Data to 4
       users, 2 of whom have not logged in for 90+ days (dormant admin
       risk). Setup -> Permission Sets -> Custom_Admin_Access.

Exit code 1 means findings were reported (this is expected on most real orgs); exit code 0 means a clean posture; exit code 2 means an error.

Step 5: Read installed-package risk

vulkro-sf org packages --target-org my-prod

This lists installed managed and unmanaged packages and flags beta / unverified ones plus packages whose namespace matches a known token-sprawl breach class (the Drift / Gainsight Connected App pattern).

Privacy re-statement

Every command above reads metadata only. Run them against a production org with confidence: the connector cannot read a single customer record by design, because it never issues a SOQL or Bulk query against business data. If your security team needs to verify this, the network calls are all Metadata API and Tooling API endpoints, observable in the sf CLI's own debug logs (sf ... --dev-debug).

Troubleshooting

Symptom	Cause	Fix
sf: command not found	Salesforce CLI not installed	Run npm install -g @salesforce/cli or brew install salesforce-cli, then re-try.
No authorization found for org my-prod	The alias is not authenticated	Run sf org login web --alias my-prod, approve in the browser, then re-try.
Session expired or invalid	The stored token lapsed	Re-run sf org login web --alias my-prod to refresh, then re-try.
INSUFFICIENT_ACCESS on a metadata read	The authenticated user lacks the Setup permission for that metadata type	Use an admin (or a user with View Setup and Configuration). The connector reads Setup-level config, never business records.
org status works but org perms is empty	The org genuinely has no over-privilege findings	This is a clean result, not an error. Exit code is 0.

Where to go next

• Live org setup - the connector architecture.
• Connected Apps detector - the Drift / Gainsight token-sprawl breach class.
• Methodology - the full coverage matrix.