Key points:

• The Claude connection: how it works. The OAuth flow, the two scopes Claude is issued, and exactly what access it grants once connected.
• The default configuration problem. A setting-by-setting breakdown of what’s exposed the moment an admin follows Salesforce’s own setup guide and stops there.
• Hardening the Claude connection. Six independent, practical controls that take a permissive-by-default integration to a minimum security standard.
• The bigger picture. Why Claude is the most visible example of a pattern that runs through every MCP client, CI/CD pipeline, and third-party tool connected to your org.
• Key recommendations. Eight actions you can take this week, in priority order.

Who is it for?

This paper is for:

• The people who will be asked by others within their company: “who connected this, and why does it still have access?”
• Salesforce administrators and platform owners rolling out Claude Code or Claude Desktop, or fielding requests to do so.
• Security and IT leaders who need to understand what an AI agent connection actually grants before they approve it.
• Anyone auditing External Client Apps, connected apps, or OAuth clients in a Salesforce org with more than a year or two of history.

Why should you read it?

Because the risk here isn’t a vulnerability. It’s a default. Salesforce’s own documentation for connecting Claude is accurate and easy to follow, but it’s a setup guide rather than a security hardening guide. Follow it to the letter and you’re left with indefinite refresh tokens, no connection alerting, and no way of telling whether the person who set it up still works at your company.

Also, this isn’t theoretical. In August 2025, attackers exploited a similar OAuth weakness: compromised refresh tokens issued to a third-party sales tool used to access more than 700 Salesforce organizations, with Palo Alto Networks and Cloudflare among the names hit. The mechanism this paper describes is the same class of weakness, arriving through a newer front door.

Technology-agnostic by design

Trust Mapping doesn’t replace your identity, access, security, or governance tooling. Rather, it complements them by asking: what’s actually being relied on, and why. The framework applies just as well to traditional Salesforce processes as it does to Agentforce, Headless 360, third-party SaaS, or whatever comes next. This paper comes from the same team behind Cloud Protection by WithSecure, trusted by Fortune 500 companies and governments to secure Salesforce environments in real time.

Markku Teerikangas

Meet the author

Ths paper is built around an in-dpeth conversation with Markku Teerikangas, Head of IT at Cloud Protection by WithSecure. He led our own Claude Code deployment, running requirements-to-production through an agent pipeline in a live org. Every control in the paper was tested against that real deployment, not assembled from documentation alone.

Download the paper

Markku is Head of IT at Cloud Protection by WithSecure, a role he has held since May 2025. He oversees the platforms and business applications that support the company’s revenue processes. He has also served on the Salesforce CPQ and Billing Customer Advisory Board, contributing strategic feedback on product direction and best practices.

Key takeaways

• Claude inherits the full permissions of whoever connects it. If that’s an admin, Claude has admin-level access, full stop.
• Refresh tokens don’t expire by default. A connection set up six months ago by someone who has since left is still valid until you configure otherwise.
• UI restrictions don’t apply to API access. Hidden fields and disabled exports do nothing once Claude is querying Salesforce directly.
• Salesforce’s own governance tools — the Agentforce Testing Center, Trust Layer, and Agent Fabric — govern agent behavior, not the integration layer itself.
• Six independent controls, implemented in any order, take you from an unmanaged default to a documented, monitored connection.