Identity and Access Management remains one of the most important foundations of Salesforce security, and these questions continue to be essential.
But Salesforce has evolved.
Modern Salesforce environments are no longer defined solely by human users interacting through a web browser. Business workflows increasingly involve AI agents, automations, APIs, integrations, external applications, and connected platforms working alongside people. As organizations adopt Agentforce, Headless Toolkit, and AI-assisted business processes, trust is no longer exercised exclusively through human users.
The challenge is no longer simply determining who can access Salesforce and what they are allowed to do. Organizations must now understand what is trusted, how that trust is established, how it extends across connected systems, and ultimately how it influences business outcomes.
What is trust?
Trust is often discussed alongside authentication and authorization.
A user authenticates, an application is authorized, an OAuth connection is approved, or a permission set is assigned.
These are all important security controls, but they are not trust itself.
Trust is the belief that people, systems, information, and connected services will behave as expected so they can be relied upon within a business workflow.
Whether a support agent relies on customer information, an integration exchanges data through an API, or an AI assistant summarizes Salesforce records, each depends upon trust.
Trust relationships
A trust relationship exists whenever part of a business workflow relies on a participant, system, service, control, or source of information to behave or function as expected. That reliance may relate to identity, information, authority, security, or the correct execution of a business process.
- Salesforce relies on Microsoft Entra ID to authenticate users correctly.
- A customer service agent relies on Agentforce to generate accurate recommendations.
- Agentforce relies on Data Cloud to provide complete and current customer information.
- A customer relies on Experience Cloud to securely handle uploaded documents.
- An organization relies on an approved integration to access Salesforce only for its intended business purpose.
Anatomy of a trust relationship
A trust relationship is more than simply deciding whether something can be relied upon. It also defines what is expected of it, the context in which that reliance applies, and the limits of the relationship.
Responsibility defines what is being relied upon, scope defines where that trust applies, and boundary defines its limits. Together, they provide a consistent way to describe how a trust relationship is intended to operate.
For example:
- Trust relationship – Support agent relies on Agentforce.
- Responsibility – Draft customer responses.
- Scope – Customer support cases only.
- Boundary – Must not send responses directly to customers.
As workflows and technologies evolve, the way a trust relationship operates may change. Governance helps determine whether the relationship still reflects its intended business purpose or whether it should be modified or withdrawn.
Trust relationships are built on assumptions
Every trust relationship is supported by one or more assumptions. These assumptions include users acting in good faith, information remaining accurate, integrations behaving as expected, AI systems interpreting objectives appropriately, and connected services operating within their intended boundaries.
Many of these assumptions traditionally remained implicit because people question unexpected behavior, adapt to changing circumstances, and apply contextual judgement. As more work is delegated to autonomous systems, important assumptions increasingly need to be made explicit so they can be evaluated as technologies, workflows, and business objectives evolve.
Consider a simple analogy.
Imagine you give a trusted neighbor a spare key while you’re away on holiday. The physical key is simply the means of access.
The trust relationship is established when you rely on your neighbor to look after your home as agreed while you are away.
The responsibility is to water the plants, collect the mail, and lock the door afterwards.
The scope is while you are away on holiday and only for caring for your home.
The boundary is that they must not use the key for any other purpose or share it outside their household without your permission.
This trust relationship depends on several assumptions. For example, you assume your neighbor will not copy the key, share it with others outside their household, or use it for any purpose beyond caring for your home.
Now imagine you discover they recently made a copy of the key and gave it to another neighbor without telling you, or the key was stolen from them.
The original terms of the arrangement have not changed, but the information available to you has. Discovering what happened provides new evidence that challenges one or more of the assumptions supporting the trust relationship.
As a result, you decide to take the key back, replace the locks, or give access to someone else instead.
The same principle applies to digital systems. If credentials are stolen or an integration is compromised, the underlying expectation that only authorized participants should access sensitive information has not changed. Instead, the incident provides new evidence that challenges the assumptions supporting that trust relationship. Governance may therefore revoke access, rotate credentials, tighten permissions, add validation, or introduce new guardrails.
Trust is established
Trust is established when a person, system, service, control, or source of information is relied upon within a business workflow.
Sometimes this decision is explicit, such as approving a Connected App, granting an integration access to Salesforce, assigning permissions to a user, or authorizing an AI agent to perform specific tasks. In other cases, trust is established more implicitly through business processes, contractual agreements, organizational policies, or longstanding operational practices.
For example:
- A Connected App is approved to synchronize customer records.
- An AI agent is authorized to draft customer responses.
- A third-party integration is permitted to exchange information with Salesforce.
- A customer is allowed to submit support requests through Experience Cloud.
Once established, that trust relationship defines the participant’s responsibilities, scope, and boundaries. Those characteristics provide a basis for evaluating the relationship as the workflow changes.
Trust is inherited
Trust rarely remains confined to its original relationship. Instead, it naturally extends through connected systems, services, and business workflows.
Consider the neighbor analogy again.
You trusted your neighbor with a spare key while you were away. If they ask their spouse to water your plants using that same key, your trust has now extended beyond the original relationship. You never directly trusted their spouse. Instead, your trust has been extended through the relationship you originally established with your neighbor.
This is trust inheritance.
Modern business workflows exhibit a similar pattern.
When Agentforce retrieves customer information from Data Cloud, the quality and accuracy of its recommendations depend not only on Data Cloud itself, but also on the systems, integrations, and business processes which produced that information. The Agentforce workflow therefore relies upon trust inherited from those upstream participants.
This pattern is not unique to AI workflows. It appears wherever trust extends through identity providers, OAuth authorizations, APIs, third-party integrations, connected services, and software supply chains. Trust placed in package repositories, software publishers, or build pipelines, for example, may be inherited by downstream systems and workflows.
Inherited trust extends the effect of an existing relationship into new participants, information, systems, or workflows. These dependencies may not be obvious when each extension is viewed in isolation. Over time, organizations may discover that systems or workflows rely on trust relationships that were never consciously considered when the original trust was established.
As trust extends across increasingly connected ecosystems, organizations should strive to make inherited trust relationships visible, not just understand where trust was originally established.
Trust is exercised
Trust is exercised through behavior. API requests, AI recommendations, automated workflows, customer interactions, and business decisions can all exercise trust relationships and influence real business outcomes.
For example:
- An AI agent automatically approves a customer request.
- An automation updates hundreds of records without human review.
- An integration synchronizes customer information with another platform.
- A support agent sends a response based on an AI-generated recommendation.
These trust relationships depend on assumptions established earlier in the workflow. When those assumptions remain valid, trust enables organizations to operate efficiently, automate work, and scale collaboration across people and technology. When they no longer hold, trust can produce unintended outcomes just as efficiently.
An AI agent may confidently generate incorrect recommendations based on manipulated information. A compromised integration may continue operating with legitimate OAuth permissions. An automated workflow may process malicious customer content because the workflow assumes all submitted information is safe to use.
In these examples, the workflow may continue to operate as designed even though the assumptions supporting its trust relationships no longer hold. Correct execution does not necessarily mean the resulting outcome remains appropriate.
Each execution can also provide evidence that reinforces or challenges the assumptions supporting those relationships, just as each use of the neighbor’s spare key provides new information about whether the original arrangement still holds.
Taken together, these concepts describe how trust is defined, supported, extended, and exercised across a business workflow.
Why this matters
Recent Salesforce security incidents have shown that compromising a business workflow does not necessarily require exploiting Salesforce itself. Instead, attackers increasingly target trust relationships through delegated authority, compromised integrations, connected applications, trusted third parties, or social engineering to achieve their objectives.
The identities involved may be legitimate. The permissions may be correctly assigned. The APIs may be functioning exactly as designed. Yet the way those trust relationships are exercised may no longer align with the organization’s intent.
This is the challenge modern Salesforce teams increasingly face.
Identity helps establish who or what is participating, while access defines what it is permitted to do. Neither, on its own, explains how reliance operates across an entire business workflow or how trust is established, inherited, and exercised within it.
Making trust visible
Recognizing that trust exists is only the first step. The next challenge is making those trust relationships visible.
Architecture diagrams and security inventories provide useful visibility into systems, identities, permissions, integrations, and other components. But knowing that a technology exists does not necessarily explain how the business relies on it.
Even when an AI assistant, integration, or application is created for a specific task and appropriately governed, the workflow around it may still depend on particular information, assumptions, boundaries, and expected outcomes that are not captured by the technology alone.
Trust Mapping adds this workflow context by making the reliance between people, systems, information, and services explicit, together with the assumptions that support those relationships.
In the next article, we introduce the Trust Mapping Framework, a structured approach for discovering trust relationships across Salesforce business workflows, surfacing the assumptions that support them, and providing the foundation for effective trust governance.
Interested in finding out more on this subject? You can download the full Trust Framework, which comes with a full toolkit for your company, below.