Is AI safe on your org?
Pointing an AI agent at a production Salesforce org raises two honest fears: could it change something, and could your data leave? This page answers both plainly - and explains why an offline, read-only, fail-closed design is the low-risk way to give AI real context about your org.
Short answer: The risk of connecting AI to Salesforce comes from two things - write access and data egress. sf-intelligence removes both. It is read-only (no create/update/delete path exists), offline (every answer is served from a local vault, with no network call), and fail-closed (write, prompt-injection, and data-exfiltration requests are refused before any tool runs). No org data leaves your machine.
The two real risks
Most "AI + Salesforce" anxiety reduces to two concrete failure modes. Be specific about which one a given tool exposes you to:
- Write / action risk. An agent with write or execute scope can change field values, deactivate automations, delete records, or run Apex - sometimes because it misunderstood you, sometimes because it was manipulated. Any tool that can deploy or mutate carries this risk.
- Data-egress risk. A tool that ships your org's metadata or records to a third-party cloud to answer questions has moved your data outside your security boundary. That may be acceptable - but it is a decision you should make deliberately, not a default.
How sf-intelligence is designed for safety
| Concern | How it's handled |
|---|---|
| Writing to the org | No write path exists. The only org contact is a read-only sf project retrieve. There is no create, update, delete, or deploy code to invoke. |
| Data leaving your machine | Offline by default. The vault is built once and stored locally; answering makes no network calls. No telemetry, no phone-home. |
| Prompt injection | Fail-closed gates. "Ignore your instructions and…", write requests, and "dump all SSN values" are refused before routing - there is no tool left to route around. |
| Record-level exposure | The vault stores schema and source, not rows. Record values are only reachable via an opt-in, capped, read-only live plane you enable yourself. |
| Supply-chain exposure | The published npm package is code only - a files whitelist keeps the vault out, and every version is grepped clean of org identifiers. |
| Trusting an answer | Every answer is labelled with provenance and confidence, so a grounded fact is distinguishable from a heuristic guess. |
Offline read-only vs. cloud connectors
The distinction that matters for a security review:
| sf-intelligence | Typical cloud AI connector | |
|---|---|---|
| Org data location | Your machine only | Vendor cloud |
| Write access | None (read-only) | Often read + write |
| Works offline | Yes, after one retrieve | No, requires connectivity |
| Source-available | Yes (audit the code) | Usually closed |
| Cost | Free | Paid / per-seat |
This is a genuine wedge, not marketing: no cloud connector - including Salesforce's own hosted MCP servers - can claim true offline operation, because answering a question requires a round-trip to their service. If "no data leaves my machine" is a hard requirement, a local vault is the only model that satisfies it.
Planning for Agentforce or agentic AI?
Before you enable an agentic platform like Agentforce, it helps to know exactly what it could see and touch. sf-intelligence is a companion tool for the developers and admins doing that prep: use it to audit field-level access, PII exposure, and permission risk offline while you design and debug your agent's topics and grounding - it does not replace or run inside the platform, it gives you an accurate, read-only map of the org first. See sharing & visibility and the permission tools.
Where it's honest about limits
- It is a metadata tool - it doesn't read record rows unless you turn on the opt-in live plane, which is itself read-only and capped.
- Answers are only as fresh as your last refresh; it stamps freshness and warns when the vault is stale rather than implying it's current.
- Static analysis has blind spots (dynamic SOQL, reflective Apex). "No references found" means "no static evidence", not a guarantee.
Frequently asked
Is it safe to connect an AI agent to my Salesforce org?
It depends entirely on what the connection can do. The two risks are write access (an agent changing or deleting org data) and data egress (org data leaving for a third-party cloud). sf-intelligence removes both: it is read-only - there is no create, update, or delete path in the code - and it answers offline from a local vault on your machine, so no org data is sent anywhere.
Does an AI tool reading my Salesforce metadata send my data to a third party?
With sf-intelligence, no. The vault is built once with a read-only `sf project retrieve` and then lives on your machine. Answering makes no network calls. Most competing tools are cloud SaaS that ingest your org metadata into their servers - a different trust model you should evaluate separately.
Can an MCP server be tricked by prompt injection into leaking or changing data?
Prompt injection is a real risk for agents with write or data-read scope. sf-intelligence is fail-closed: write requests, prompt-injection attempts, and record-value exfiltration requests are refused before any tool runs. Because it has no write path and stores schema rather than record rows, the blast radius of a successful injection is bounded to read-only metadata questions.
What is the safest way to give an AI agent Salesforce context?
A read-only, offline, least-privilege connection. Give the agent a local metadata snapshot it can reason over instead of a live, write-capable API session. sf-intelligence is built around exactly that model, and it labels every answer with its provenance and freshness so you can tell a grounded fact from a guess.
Read-only. Offline. Fail-closed.
Give AI real context about your Salesforce org without a write path or a data upload.