Identity and access aren’t the whole picture anymore

Modern Salesforce workflows involve human users, AI agents, integrations, APIs, and downstream processes all acting on each other’s behalf. An integration can be securely configured, correctly permissioned, and still no longer serve the business purpose it was built for. An AI agent can operate entirely within its granted access and still produce outcomes nobody intended.

Trust isn’t just granted once: it’s established, inherited, and exercised. And it drifts.

What to expect

The Trust Mapping Framework Five domains – Entities, Information, Connections, Actions, and System Outcomes – that make trust relationships visible across any Salesforce workflow, regardless of technology.

Trust Mapping Discovery A practical method for identifying who and what participates in a workflow, what’s relied upon, and how trust is established and extended, before you try to govern it.

Trust Mapping Governance A structured way to evaluate evidence and decide whether a trust relationship should continue, be modified, or be retired.

Trust Drift patterns Recognizable failure patterns, including Orphaned Trust, Excessive Trust, and Autonomous Actions Without Oversight, with governance questions for each.

Real-world examples Three real-world-style scenarios (Claude + Headless 360, Agentforce customer service, and an integration prototype gone stale) showing how trust relationships change over time even when nothing was technically “broken”.

Who is it for?

This whitepaper has been built for the people accountable for Salesforce trust.

Security, risk, and compliance leaders governing an increasingly autonomous Salesforce estate. Salesforce architects and platform owners rolling out Agentforce, Headless 360, or third-party integrations. Anyone who has ever asked “why does this still have access?” and not gotten a satisfying answer.

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.

Karmina Aquino

Meet the author

Karmina Aquino has worked in cybersecurity for more than 20 years, mostly across threat detection, analysis, intelligence, and security operations. Currently, Karmina leads threat intelligence for Cloud Protection by WithSecure, spending a lot of time looking at how attackers are using Salesforce environments, how the platform is evolving, and where new risks are starting to emerge.

Download the paper

“I wasn’t planning to write a framework or a whitepaper. I was preparing a Dreamforce talk on the Salesforce threat landscape, trying to explain the attacks we were seeing.

One pattern kept showing up. The incidents weren’t usually attackers exploiting Salesforce itself. They were exploiting things already trusted: legitimate identities, OAuth connections, integrations, workflows, content, and increasingly, automation and AI.

Then I realized the same issue exists with no attacker at all. A system can be configured correctly, permissions can be right, everything can work as designed, and still the business’s reliance on it, or the assumptions behind that reliance, may no longer hold.

That’s when the question shifted: how do you make these trust relationships visible? What does a workflow rely on, why, what are its boundaries, and how do you know when something’s changed enough to warrant review? That became Trust Mapping, a way to make the trust relationships inside connected business workflows visible enough to govern deliberately.”