2026 · Headless 360
ORG/LAB · Salesforce security architecture, practised in a live org and AI audited
As a business analyst, I want the org audited, so that I can prove build matches design.
The Build
ORG/LAB is two builds joined into one. The first is a drill console for the Salesforce Sharing and Visibility Architect certification: thirty blueprint-first exercises drawn from the exam syllabus, built along in a real Developer Edition org rather than answered from flashcards. The second is the headless architecture underneath, an OAuth-governed Model Context Protocol connection that lets Claude read that same org directly. Together they close the loop: configure a permission set or a sharing rule, and the audit reads the org's actual state, tells you what you built, and names the trade-offs you could not defend.
The Approach
The connection is governed from the first step, because an auditor that can change the org is not an auditor. A secretless public-client OAuth pattern, consumer key plus PKCE with no client secret ever issued, exactly two scopes, least-privilege servers set to read and metadata only, and standard Salesforce permissions on top. Claude can read everything the authenticating user can, and change nothing. Both routes were built end to end in a Developer Edition org, hosted (GA) and local (Beta), and the whole capability rebuilds from a runbook in about an hour.
Two routes: the hosted route (OAuth, generally available) reaches any Claude surface; the local route (CLI, Beta) runs on the workstation. Local first, hosted second.
Fig. 01 · How the connection is made
Every hop is a decision. Here is each one, and why.
Four layers sit between the AI and the org, and not one is incidental. Every hop was a security decision taken before the capability existed, and the whole chain is inspectable: you can see exactly what was granted, and exactly what was withheld.
Fig. 02 · The tool, and the audit
Connection landed. Now read the real org.
Author's own work, own dev org · standard Salesforce sample data
Judgement Call
Design the safety case before the capability. The quick version of this build connects an agent and grants it broad access; it works, and no security reviewer would approve it. This one was built the other way round: two scopes, read and metadata only, no client secret issued, and write endpoints off by decision rather than by accident. The test was whether it could be explained to a reviewer on a single page.
What this demonstrates
- Both architectures configured end to end: hosted OAuth 2.0 with PKCE, and local CLI-authenticated
- A least-privilege, secretless design: read and metadata only, exactly two scopes, no client secret ever issued
- Self-checking behaviour: the agent caught a wildcard over-match in its own query and corrected it against the authoritative Tooling API
- A vendor-side token defect isolated by systematic elimination and escalated with a full diagnostic case file
- A runbook that rebuilds the whole capability from scratch in about an hour
Scope and limitations
A working, governed interface to a live org, and, more usefully, a repeatable pattern: propose the capability, design the governance first, prove it with an acceptance test, and keep the human permission model as the ultimate authority. Stated plainly: the hosted route's reach across web and mobile currently waits on an AI-vendor fix; the Salesforce side is complete and verified. The capability is deliberately no more powerful than the governance around it.