Discovery and Governance answer different questions.
Discovery asks:
- What trust relationships exist?
- What assumptions support them?
Governance asks:
- Do we have sufficient and current visibility into the trust relationships that require Governance attention?
- Who is accountable for the relationship and for reviewing it?
- Why is it relied upon, and does its purpose, scope, and boundaries remain appropriate?
- Would we know if the relationship, its assumptions, or supporting evidence changed?
- Does available evidence still justify the relationship, and should it be maintained, modified, or withdrawn?
Discovery aims to make the key trust relationships within a workflow visible, while Governance can prioritize attention according to business significance and risk. The principle is similar to vulnerability management: visibility can be broad, while attention is focused where it matters most.
Together, these steps show how Trust Mapping moves from visibility to evidence-based decisions.
Governing through the five trust domains
The same five domains used during Discovery are also used during Governance to examine whether the trust relationship still operates as intended across its participants, information, connections, actions, and outcomes.
The domains provide different perspectives for evaluating the trust relationship. Together with the available evidence, they help inform the Governance decision. Because the domains are technology-agnostic, the same approach can be applied across workflows involving Salesforce users, AI agents, integrations, and other technologies.
Governing the Agentforce workflow example
In the previous article, Discovery revealed several trust relationships within the customer support workflow example.
One of those relationships was:
- Trust relationship: Support agent relies on Customer
- Responsibility: Provide information needed for support
- Supporting assumption: Submitted content is safe for the support workflow and Agentforce to process
When evaluating that relationship during Governance, the discussion might look something like this:
New evidence
The customer account has been compromised and begins submitting malicious content through the normal support workflow. The workflow continues to process that content as expected, challenging the assumption that submitted content is safe for the workflow and Agentforce to process. If information from the affected case is later used to update knowledge content, the effect may also extend into future support workflows.
Governance evaluation
Questions based on the trust domains include:
- Does the assumption that submitted content is safe still hold?
- Should customer-submitted content continue to be treated as trusted input in the same way?
- Could affected case information become trusted input for downstream workflows?
- What validation, monitoring, or controls should change?
Governance decision
Continue using Agentforce, but modify the trust relationship by:
- Scanning customer submissions for malicious content or manipulative input before they are processed by Agentforce.
- Monitoring Agentforce behavior and downstream outcomes for unexpected effects.
- Validating case information before it is used to create or update knowledge content.
Retain human review before responses are sent.
Governance is not evaluating Agentforce in isolation. It is evaluating whether the trust relationship, its supporting assumptions, and the way information flows into downstream processes still align with the organization’s intent.
Trust mapping across the relationship lifecycle
Trust relationships change as workflows, technologies, participants, and business objectives evolve. Over time, new evidence may strengthen or weaken confidence in the assumptions that support them.
As AI systems gain new capabilities or operate in new contexts, new evidence may challenge assumptions that previously supported a trust relationship, even when permissions, identities, or underlying technologies have not changed. At the same time, integrations evolve, workflows expand, partners gain access to new systems, and information begins flowing through new paths.
These developments do not necessarily indicate a security incident, but they may affect whether a trust relationship still operates within its intended purpose, scope, boundaries, and supporting assumptions.
Trust Mapping is therefore not a one-time exercise. Discovery and Governance may both be revisited periodically and when new evidence or changes in the workflow warrant reassessment.
Sufficient monitoring, observability, and explainability are important because they provide the evidence needed to determine whether the assumptions supporting a trust relationship still hold.
That evaluation continues throughout the relationship’s lifecycle, from when trust is first identified and established through its operation and eventual retirement.
The objective is not to eliminate trust, because businesses depend on it to operate. Instead, the objective is to ensure that trust continues to support the organization’s intended outcomes.
Where Trust Mapping fits
Trust Mapping is intended to complement existing security, architecture, risk, and governance practices rather than replace them. Those practices may examine many of the same identities, applications, integrations, permissions, and information, but often from different starting points and perspectives. Trust Mapping adds a workflow-level view of what the business relies upon, why that reliance exists, and what assumptions support it.
These approaches can inform one another. Existing practices can provide controls, evidence, and specialist perspectives, while Trust Mapping helps connect those findings to the business workflow they support.
A technology inventory may tell us that an application, agent, or integration exists, but not necessarily how it is relied upon in different workflows. The same technology may support different purposes, operate within different boundaries, and depend on different assumptions depending on the context.
An integration, for example, may be securely configured, appropriately monitored, and limited to its intended permissions. Yet, the workflow may no longer need it, or the assumptions supporting that reliance may no longer hold. Conversely, a security finding may become more meaningful when the workflow shows that some access or behavior falls outside the purpose for which that relationship exists.
Bringing it all together
Together, the Framework, Discovery, and Governance provide a way to move from making trust visible to evaluating whether those relationships remain appropriate as they evolve over time.
As enterprise AI continues to evolve, much of the discussion will understandably focus on building agentic systems, securing AI models, protecting endpoints, strengthening identity governance, and responding to new attack techniques. These remain important, but they answer different questions.
Trust Mapping asks a complementary one:
How should organizations identify and manage the trust relationships that different business workflows rely upon?
That question becomes especially practical when new capabilities and architectures are being designed. For modern Salesforce architects, the question is increasingly not only:
Can we build this?
but also:
What new trust relationships does this create, and how will we know whether they continue to deserve our trust?