Briefly: everything that decides whether Claudeforce is safe in your org is configurable today, before the pilot reaches you. An agent runs as the authenticated user through an External Client App with the mcp_api scope, so your sharing model, field-level security and permission sets are the control surface. Four days of work, none of it wasted if you never connect an agent at all.
The readiness steps below are testable in any org right now, and the Setup pages named exist in a current Developer Edition org. The Claudeforce pilot itself is closed, so the product behaviour is quoted from the hosted MCP documentation rather than tested. Checked September 2026.
Day one: find out what an agent would be able to read
Not what it should read — what it could. Three queries and a list.
Who holds View All or Modify All? Those two permissions ignore the sharing model entirely, so any user holding them hands an agent the whole object. Check every profile and permission set, not just the obvious admin ones. The list is always longer than expected, and it is the shortest path to a surprise.
What can a normal user actually see? Pick your two most common profiles, log in as one, and count the records on your main objects. Compare that with what the business believes those people can see. Any gap is a finding, and it exists whether or not an agent ever arrives.
Which fields are readable that nobody reads? This is the one that matters most, because breadth is what changes. Six categories to check: money that is not the price, internal opinion, scores and predictions, personal data, legal and compliance flags, and anything from HR.
Day two: decide who may connect, and write it down
Access can be restricted with an app policy that pre-authorises only users holding named profiles or permission sets. That is the control to ask for by name, and it turns “who may connect an external tool” from an unanswered question into a configuration.
Decide three things and record them somewhere a successor will find:
- Which roles are eligible. Start narrow — one team, named people. Widening later is a decision. Narrowing later is a retraction.
- Whether connecting requires approval, and from whom. If the answer is “nobody has said”, that is the finding.
- What happens when someone leaves. Deactivating a user should end their agent’s access, which it does when the agent runs as them — one more reason that model is the right one.
Day three: fix the field-level security you have been meaning to
Take the field list from day one and make a decision per field, not per object. For each: is it still correct that this profile can read this, given it can now be read in bulk and restated in prose?
Most fields survive that question. A handful will not, and they are usually the ones added quickly for a project that ended. Removing read access from a field nobody has opened in two years costs nothing and closes the gap permanently.
One caution: do not do this the week you connect an agent. Field-level security changes break reports, list views and integrations in ways that surface days later, and you do not want that noise landing at the same time as a pilot.
Day four: work out how you would notice
Access review tells you what is possible. This tells you what happened, and it is where most orgs are weakest.
Three questions with honest answers required. Is each read recorded, and where? Can you attribute a read to the person who asked rather than to a connection? Would a ten-times jump in read volume at 3am reach a human?
If the answers are no, no and no, you do not have an audit story. Event Monitoring is the platform answer where it is licensed. Where it is not, API usage and Login History are the crude substitute, and Login History is already the best inventory you have of what connects to your org.
What not to do
Do not create a shared integration user for it. It looks simpler and it moves your access boundary from the sharing model to a chat window, while making every audit entry name a connection rather than a person. The documented path runs as the authenticated user. Keep it that way.
Do not wait for the pilot to start the access review. The review takes days and the pilot arrives with a date attached. Teams that begin when the invite lands do the review badly, under pressure, with somebody asking when it will be finished.
Do not build against the API yet. Skills are still launching through late 2026, and a pilot API is not a foundation.
The part that is genuinely valuable either way
Every step above is work you would do before any external tool touches your org: a new middleware platform, a partner portal, a reporting connector, a different vendor’s agent. None of it is Claudeforce-specific, and none of it is wasted if you decide against it.
That is the real argument for starting now. An agent connection is a forcing function for an access review that was already overdue, and the review is the deliverable. The pilot is just what finally got it scheduled.
Frequently asked
How long does the access review actually take? Four days of focused work for a mid-size org with a normal amount of accumulated permission debt. Longer if nobody has audited View All in a few years, and that length is itself the finding.
Do we need Data Cloud first? Nothing in the announcement makes it a prerequisite for the sales plugin. Unknown until documented, and worth asking rather than assuming.
Can we test any of this before the pilot? The access review, yes, entirely. The connection, no. That is the split, and it is why the review is where to spend the time.
What if we decide not to use it? You will have an access review, a written policy on who may connect external tools, and a tighter field-level security model. That is a good quarter’s work regardless of which vendor’s agent turns up next.
