Part 2 of The AI Governance Moment: A Practical Series on Saying Yes to AI Without Losing Control.
On a Saturday morning, a VP of sales connects Claude to Salesforce and asks which deals over $100,000 haven’t moved in 30 days. Claude pulls the list. The VP asks which of those have no next step logged, and Claude narrows it to fourteen deals and suggests close dates that look more realistic. The suggestions make sense, so the VP asks Claude to update them. A few minutes later, eleven opportunities have new close dates and two others have moved to a new stage.
It was a productive Saturday morning. By Monday, the VP is wondering whether Claude touched only those thirteen records, and whether the reps who own the deals will know the new dates came from an AI session. Underneath sit two quieter questions. What did Claude read along the way? And what did the morning cost? Claude usage is billed by the token, and nobody set a limit before the VP connected.
Most teams worry about the changes first and treat read access as the safe default. That’s the wrong half to watch. Before Claude ever updates a record, it has already read whatever the VP’s permissions allow, and in many orgs that’s far more than the VP has ever seen on a screen. In our customer work, read access is where the security model gets tested first, because many security models were never built with agents in mind.
What the layout was hiding
For years, a lot of Salesforce orgs have used page layouts as a quiet security filter. A field nobody should see gets left off the layout, and in the Salesforce interface it effectively disappears. The problem is that a layout only controls what a person sees on the page. The permissions underneath can still allow access to that field.
An agent doesn’t look at page layouts. Salesforce’s guidance on securing its hosted MCP servers says MCP tools run with the same permissions as the user who connected, which means object access, field-level security, and sharing rules. So a salary field, a discount approval note, or a sensitive case comment that was hidden from a layout for years can show up in an agent’s answer on the first day. The agent didn’t create that gap. It found one that was already there.
Experienced admins know the difference between a layout and a permission. Most orgs also carry years of shortcuts where one stood in for the other, made under deadline by people who have since moved on. One org we’ve worked in had a couple hundred permission sets and over a hundred connected apps before anyone added an agent.
What Dana sees in Salesforce
7 fields on her layoutWhat Claude can read for Dana
How to get to yes
All of this leads to the question teams ask us next: how to connect Claude to Salesforce securely and responsibly, without stalling the work people are already excited about. Our answer is to open access in three stages. Crawl secures the foundation before anyone connects. Walk opens read-only access to the data you choose. Run adds governed write access and keeps building from there. Each stage adds access only after the one before it is secured. Spend is tracked and managed in every stage too, since broad questions across large Salesforce objects add up quickly.
Crawl: secure the foundation
Crawl solves the problem that stalls most of these conversations: nobody can say with confidence what an agent acting for a given person could see, change, or cost. Most Salesforce security models grew over years of exceptions and shortcuts, and nobody reviewed them with an agent in mind. Crawl closes the gaps that matter for the first use cases and puts spend limits in place before anyone connects. Where it helps, agent access gets its own identity so it can be watched and switched off on its own. Salesforce announced its version of this, Agentic Identity, in September, and it’s still being worked out, so we expect this piece to keep changing.
The win is a clear answer. Your security owner can say with confidence what Claude will be able to see, finance knows the ceiling on spend, and the request that’s been stuck in review finally has a path forward.
Walk: controlled read-only access
Walk solves the problem people feel most: the hours they spend digging through Salesforce for the records, history, and context their work depends on. Some have already started exporting reports and pasting them into AI tools with no controls at all. Walk gives a first group read-only access to the Salesforce data you’ve chosen to make available inside Claude, and nothing beyond it.
The win shows up quickly. Questions that used to take an afternoon of clicking get answered in a few minutes, and the account briefs, meeting prep, and proposals people produce every week start from real data. Walk also shows what people actually ask for, which is the best evidence for deciding what to build next.
Run: governed write access, then keep building
Run solves the harder problem: letting AI change data in Salesforce without putting the system of record at risk. The usual safeguard, a prompt asking someone to approve each change, stops working once people click through without reading. In run, the protection is built into the tools themselves, so each one can only change what its job requires.
The win is work that used to depend on someone remembering to do it. Pipeline stays current, follow-ups get logged, and records reflect what actually happened, with a trail behind every change. Run also keeps going. Claude and your org both keep changing, and the value comes from building, measuring, and refining as they do.
Think back to the VP’s Saturday morning. After crawl, the security owner knows exactly what Claude can see on the VP’s behalf. In walk, Claude answers every question about stalled deals using only the data it was approved to read. In run, the new close dates go to the reps who own those deals, they accept the ones that are right, and every change leaves a record. The VP gets the same productive Saturday, and nobody has to worry on Monday. That’s what a confident yes looks like.
Are you ready to get to “yes”? We’ve built a crawl, walk, run methodology that gets Salesforce data working in Claude fast, with access and spend under control.
Contact us to start the conversation.
In Part 3, we’ll look at how companies turn all of this into a process people actually use.