The rapid infusion of artificial intelligence into Salesforce ecosystems is prompting a fundamental reassessment of how organizations approach security and governance. While legacy controls centered on user identities, role‑based permissions, network configurations, and patch management remain essential, they no longer capture the full spectrum of risk introduced by autonomous agents and data‑driven workflows. AI‑enabled features such as predictive lead scoring, generative content creation, and conversational bots now operate with varying degrees of independence, making decisions that were once the exclusive domain of human analysts. Consequently, security teams must expand their purview beyond static access lists to evaluate the dynamic trust placed in algorithms, data pipelines, and third‑party services that interact with CRM data. This shift demands a new mindset: rather than asking only whether a user is authorized, practitioners must interrogate whether the information fed into an AI model is reliable, whether the model’s behavior aligns with business intent, and whether the outcomes produced by automated actions can be trusted downstream. By embracing this broader view, enterprises can harness AI’s productivity gains while mitigating the emergent risks that traditional frameworks overlook.
Historically, Salesforce governance has relied on a checklist mentality that validates identity federation, permission sets, sharing rules, and security settings such as login IP ranges or session timeout values. These controls excel at preventing unauthorized data exfiltration or malicious configuration changes, yet they assume a relatively static relationship between who can access data and how that data will be used. In contrast, the emergence of AI agents introduces a fluid boundary where the same set of credentials might enable a model to generate insights, trigger downstream automation, or even modify records without explicit human oversight. This evolution necessitates a governance model that examines not just who is allowed to act, but what those actors are expected to do, under what conditions, and with what limitations. By reframing security as a question of trust—confidence that a system, person, or data source will behave predictably within a defined workflow—organizations can surface hidden dependencies that traditional audits miss. Such a perspective also clarifies why certain integrations, though technically compliant, may still pose risk if the underlying assumptions about data freshness, model accuracy, or process continuity no longer hold true.
At the heart of this new paradigm lies the concept of a trust relationship, which the WithSecure paper defines as the belief that a participant—whether a human user, an AI agent, an API, or an external service—will perform as anticipated and therefore can be relied upon to support a business objective. Unlike a simple permission grant, a trust relationship encompasses multiple dimensions: it specifies what is being depended upon (the responsibility), delineates where that dependence applies (the scope), and sets explicit limits that prevent overreach (the boundary). Furthermore, each relationship rests on a set of assumptions about the environment that make the reliance feasible, such as the availability of accurate data, the stability of a third‑party service, or the continued validity of a model’s training data. When any of these elements shift, the underlying trust may erode, potentially exposing the organization to unintended consequences. By making these components explicit, security teams can move beyond vague feelings of confidence or concern and instead engage in structured analysis that pinpoints exactly where confidence is justified and where it requires reinforcement.
Understanding the anatomy of a trust relationship provides a practical lens for evaluating Salesforce‑centric workflows. The responsibility component answers the question of what the trusted party is expected to contribute—whether that is delivering accurate sales forecasts, enforcing discount approval rules, or synchronizing customer records with an ERP system. The scope defines the contextual boundaries of that contribution, such as a specific product line, a geographic region, or a limited time window. Boundaries, meanwhile, act as safeguards that prohibit the trusted entity from straying into unauthorized territory, for example by restricting an AI model’s access to only non‑personal data or by capping the number of records a bulk API call can modify in a single transaction. Finally, the supporting assumptions capture the preconditions that must hold true for the relationship to remain viable; these might include assumptions about data latency, the absence of conflicting automation rules, or the continued compliance of a third‑party vendor with data protection regulations. When any of these facets change—say, a new data source is introduced or a vendor updates its API—the trust relationship must be re‑evaluated to ensure it still aligns with organizational goals and risk tolerance.
The proliferation of AI and automation within Salesforce amplifies the complexity of trust relationships by extending them across multiple tools and processes that previously operated in silos. Consider a scenario where an AI‑driven lead enrichment service pulls data from a public web scraper, enriches it within a custom Heroku app, and then writes the enhanced profiles back into Salesforce via the Bulk API. Each step introduces its own set of trust dependencies: confidence in the scraper’s data quality, reliance on the Heroku dyno’s uptime, and faith in the API’s permission boundaries. When these interactions occur without direct human intervention, the traditional checkpoint of a user approving each action disappears, placing greater emphasis on pre‑established trust models. Moreover, as AI agents begin to orchestrate multi‑step processes—such as automatically generating a quote, routing it for approval, and updating the opportunity stage—the trust chain becomes longer and more intricate. Each link in the chain must be vetted not only for its individual reliability but also for how failures or unexpected behaviors might propagate downstream. Consequently, organizations need a holistic view that maps these interdependencies, enabling them to identify single points of failure and implement compensating controls before a breach or erroneous decision can cause material harm.
To operationalize this expanded notion of trust, the WithSecure paper introduces the Trust Mapping Framework, a structured methodology that examines trust across five interrelated domains. The first domain, entities, enumerates all participants that contribute to a workflow—people, AI models, services, devices, and data stores. The second domain, information, captures the data elements that flow between these entities, noting their sensitivity, provenance, and any transformations they undergo. The third domain, connections, details the mechanisms by which entities exchange information, such as APIs, middleware, file transfers, or shared databases, and includes the associated authentication methods and protocol versions. The fourth domain, actions, describes the operations performed on the information—reads, writes, calculations, deletions, or decisions made by an AI model. Finally, the fifth domain, system outcomes, records the tangible results of the workflow, such as a closed‑won opportunity, a updated customer sentiment score, or a triggered marketing campaign. By systematically populating each of these domains, practitioners can visualize where trust is placed, how it is established, and what assumptions underlie each link. This holistic map serves as a foundation for both discovery and ongoing governance, allowing teams to move from anecdotal impressions to evidence‑based assessments.
The framework’s applicability extends beyond native Salesforce features to encompass the broader ecosystem that modern enterprises rely upon. It can be applied to Agentforce deployments, where autonomous bots handle routine service inquiries; to Headless 360 implementations, which decouple the CRM’s data layer from custom user interfaces; to third‑party SaaS applications that sync marketing automation, finance, or support data; and to any AI‑assisted workflow that leverages Salesforce as a source or destination of information. Because the model is agnostic to the underlying technology, it provides a common language for security architects, business analysts, and data scientists to discuss risk in a unified manner. For instance, when evaluating an AI‑driven forecasting tool, the entities domain would list the forecasting model, the Salesforce data lake, and the BI dashboard; the information domain would capture historical opportunity fields, external market indicators, and the forecast output; the connections domain would detail the OAuth‑secured REST calls and the scheduled ETL jobs; the actions domain would note the model’s training, inference, and write‑back steps; and the system outcomes domain would reflect the updated forecast displayed to sales leaders. This comprehensive view ensures that no critical dependency is overlooked, thereby strengthening the organization’s ability to govern AI‑enhanced processes with confidence.
Trust Mapping begins with a discovery phase that seeks to surface the latent relationships that enable a business workflow to function, even when those relationships are undocumented or taken for granted. Rather than starting with assumptions about security, practitioners ask fundamental questions such as: Which systems or individuals contribute to this process? What data do they consume and produce? How is trust established—through certificates, API keys, service accounts, or human endorsement? What actions are permitted, and what guardrails exist to prevent abuse? What are the intended business outcomes, and how do they affect downstream operations? By answering these questions, the discovery process yields a catalog of trust relationships, each annotated with its responsibility, scope, boundary, and supporting assumptions. This explicit articulation allows organizations to evaluate whether each relationship remains fit for purpose, justified by current business needs, and aligned with the organization’s risk appetite. Moreover, it highlights any gaps where trust is implicit but unverified, prompting the addition of controls or monitoring where necessary. The discovery stage thus transforms intuitive trust into a tangible artifact that can be reviewed, challenged, and refined as technology and business objectives evolve.
The paper illustrates the discovery process through three concrete scenarios that demonstrate how trust relationships can shift after they are first established. In the first example, a sales representative utilizes a generative AI model—such as Claude—accessed through a Headless 360 interface to analyze historical opportunity data and receive recommended next steps. Initially, the trust relationship might assume that the AI receives only sanitized, aggregate data and that its suggestions are merely advisory. Over time, however, if the model begins to ingest personally identifiable information or if its recommendations are automatically executed without human review, the underlying scope and assumptions have changed, potentially exposing the organization to privacy violations or erroneous decisions. The second scenario follows a customer service ticket that is first triaged by an Agentforce bot, which gathers details, suggests a resolution, and then escalates to a human agent for final approval. Here, trust extends from the bot’s natural language understanding to the accuracy of its suggested fix; if the bot’s model drifts or if the escalation workflow is bypassed, the trust chain weakens. The third scenario highlights a lingering risk: a legacy integration that was decommissioned but whose service account credentials remain active in the environment. Though the integration no longer serves a business purpose, the persistent credentials create an orphaned trust relationship that could be exploited by an attacker seeking a foothold into Salesforce.
Once key trust relationships have been identified through discovery, the governance phase evaluates each one to determine whether it should be maintained, adjusted, restricted, or retired. This evaluation revisits the five domains of the Trust Mapping Framework while weighing factors such as visibility—whether the relationship is adequately logged and monitored; ownership—who is accountable for its performance and compliance; purpose—whether the relationship still supports a defined business objective; monitoring—what telemetry exists to detect anomalous behavior; and review—how often the relationship is reassessed in light of changing conditions. Practitioners also examine whether the appropriate individuals or systems retain the authority to act, whether the information flowing through the chain remains accurate and timely, and whether the actions performed stay within the prescribed limits, such as API rate caps or data classification boundaries. Additionally, they consider the broader impact of the workflow’s outcomes on other processes—for example, whether an AI‑generated discount approval might inadvertently violate pricing policies in a downstream billing system. Based on this holistic assessment, organizations can decide to preserve the relationship as‑is, tighten its scope, introduce additional validation steps, impose stricter monitoring, or decommission it entirely if the risk outweighs the benefit.
A critical phenomenon that underscores the need for continuous vigilance is trust drift—the gradual divergence of a trust relationship from its original purpose, scope, limits, or supporting assumptions. Trust drift can manifest in several familiar ways: orphaned service accounts or API keys that persist after a project is sunsetted, excessive permissions that accumulate through role‑expansion creep, reliance on outdated reference data that no longer reflects current market conditions, or the uncritical acceptance of AI‑generated insights without independent validation. Each of these conditions represents a silent erosion of the safeguards that were initially put in place to ensure predictable behavior. Because trust drift often occurs incrementally, it can escape detection by periodic audits that focus solely on static configurations. Instead, organizations must adopt a dynamic monitoring approach that tracks changes in permission grants, observes deviations in model output distributions, and correlates anomalies with business‑process events. By treating trust as a living property that requires regular maintenance, security teams can catch drift early, apply corrective controls such as re‑scoping OAuth scopes, refreshing training data, or enforcing re‑approval workflows, thereby preserving the integrity of the CRM environment while still harnessing the advantages of automation and AI.
Ultimately, the Trust Mapping approach does not seek to replace established practices such as security posture management, threat modeling, or identity governance; rather, it complements them by adding a workflow‑centric layer that illuminates the why behind each dependency. This perspective enables organizations to answer strategic questions with greater precision: Is this AI‑driven recommendation truly reliable? Does this integration still deliver value commensurate with its access? Are the assumptions that underpin our automation still valid in light of recent regulatory changes or market shifts? To operationalize these insights, practitioners should begin by selecting a high‑impact, cross‑functional workflow—such as lead‑to‑opportunity conversion or case‑resolution—and run a Trust Mapping discovery exercise. Document the entities, information, connections, actions, and outcomes, then engage stakeholders from security, business, and data science to validate the map. From there, establish a regular cadence—quarterly or semi‑annual—by which the map is reviewed, updated, and re‑governed, particularly after any major system change, vendor switch, or AI model retraining. By embedding trust mapping into the ongoing governance lifecycle, enterprises can confidently innovate with Salesforce AI while keeping risk firmly in view.