The case for AI personalization in fintech has largely been made. 

But as personalization scales, so does the amount of customer data being put to work, and the scope of what AI agents can do with it. Risk tends to scale alongside.

The challenges around agentic AI in fintech, therefore, extend well beyond adoption. NVIDIA’s State of AI in Financial Services, based on a survey of more than 800 industry professionals worldwide, shows how broad those challenges are. 

Performance reliability, covering accuracy, drift and unpredictable results, was cited most often, by 34% of respondents, followed by a lack of internal skills to manage or monitor agents at 33%. Data-related issues such as privacy and sovereignty came in at 30%, while implementation and integration hurdles and regulatory and ethical concerns were each cited by 28%. The spread is fairly even, which suggests these challenges have to be addressed across the pipeline.

For fintech, those challenges carry added weight. Firms hold large reserves of sensitive customer data, and agents are increasingly positioned to act on it, which raises the stakes on every item in that list, from reliability to data handling to regulatory exposure. 

The question is how to orchestrate that agentic capability responsibly. Agentforce Trust Layer is designed to address and contain risks in the agentic ecosystem. However, it does not eliminate the need for organizational guardrails and measures to work alongside it.

What does the Agentforce Trust Layer govern? 

The Trust Layer is a set of controls that sits between a Salesforce application and the large language model (LLM). It governs four areas for fintech teams: what data an agent can retrieve, what the model receives, what the agent is allowed to do, and what gets logged for audit. 

At a high level, the flow has three stages: the prompt journey, response generation, and the response journey. Salesforce describes the Trust Layer as sitting between the Salesforce application and the LLM. Prompts and relevant data pass through it on the way to the LLM, and the generated response passes back through it before returning to the CRM app or Agentforce agent that made the request. 

For an enterprise fintech team, four areas matter most:

1. Data access 

An agent needs context for personalization. The context might include customer records, account information, interaction history, application status, policy information, etc. 

The Trust Layer’s secure data retrieval respects Salesforce’s existing access controls. Data required for grounding is retrieved based on the permissions of the user executing the interaction, including relevant record and field-level security. 

If a field or record is restricted from the executing user, it is automatically excluded from the AI’s grounding context. 

Personalization should be based on authorized context, not simply the largest possible pool of customer data available. This is basic to fintech operations.  

2. What the model receives

The next question is what happens after the relevant data has been retrieved. 

The Trust Layer provides a secure path between Salesforce and supported model providers. Salesforce’s current documentation describes a zero-data-retention policy for data sent to external LLM providers through the Trust Layer. The provider does not retain the data or use it for training after the response is returned. 

There is an important architectural boundary here. 

If a developer in your team makes a direct call from Apex or another mechanism to a third-party LLM endpoint, the interaction is not Trust Layer-protected. Any customer data is sent directly to that model provider, subject to that provider’s data-handling and retention policies. This creates a data-handling boundary that you’ll need to govern. 

To ensure every request is protected by Trust Layer, consider using Salesforce-supported mechanisms, such as Prompt Templates or the Models API. 

3. What the agent is allowed to do 

Data access is only half the challenge in governance. An agent may have access to information but still need boundaries around what it can actually do with it.

Agentforce uses topics, instructions, actions, permissions, and other controls to define agent behavior. Salesforce also describes AI and security guardrails intended to reduce hallucinations, defend against prompt injection, and constrain agent behavior.

Trusted agentic behavior encompasses policy adherence, human-agent teaming, observability, operational controls, safety, security, privacy, legal compliance, and ethical compliance as parts of the problem.

For example, an agent may be permitted to summarize a customer’s application but not approve a loan. It might retrieve the status of a claim but escalate a disputed decision. It might prepare a payment action but require an explicit confirmation before execution.

The boundary has to be designed. 

4. Audit trails

The final requirement is auditability. Salesforce provides audit mechanisms covering Trust Layer activity, including prompt and response information, masking activity where applicable, and trust-related signals. It also features reports and dashboards built on the underlying Data 360 data model. Prompts, responses, and trust signals can be logged and stored in Data 360 for visibility into user interactions. 

Importantly, don’t confuse audits with exposing an LLM’s private chain of thought.

In the enterprise context, what you need is operational evidence like:

• which request came in
• what data and actions were involved
• what controls were applied 
• whether the response satisfied the configured requirements 
• what action occurred 
• whether the interaction was escalated

Example: Agentforce in a retail bank credit-limit journey

A retail bank’s customer asks the app’s chat agent whether she can get a higher limit on her credit card. The agent is set up to personalize the conversation.

The agent pulls together her recent spending, card tier and interaction history. The Trust Layer’s secure data retrieval limits this to what the agent’s permissions allow, so the internal credit risk score stays out of the information sent to the model. The agent can still explain how limit reviews work, without touching risk data.

Then, while explaining why she wants the increase, she mentions she’s been struggling to keep up with payments. The agent doesn’t suggest anything further. The conversation passes to a human rep, with her request and spending pattern already summarized, since approving a limit isn’t among the actions the agent has.

The whole interaction is logged to the Trust Layer’s audit trail for later review.

Below is a top-level view of the journey. 

The most telling moment in that journey is the one where nothing happens. A customer who mentions payment trouble is not handed another product. What the agent is meant to optimize for is a design decision, and it was made before the conversation began. 

The stakes of getting it wrong are spelled out by Cintia Barcelos, CTO of Bradesco in this Forbes article, published on September 30, 2026:

“If AI systems are designed only to stimulate transactions, they may reinforce harmful incentives, such as encouraging excessive use of overdraft facilities, extending credit to customers who are already over-indebted or prioritizing products that generate higher returns for the institution rather than better outcomes for the customer.” 

Personalization is meant to empower, not manipulate, the customer, as she rightly argues.

Compliance questions for agentic AI in fintech 

“What data can the agent access?”

Begin with the Salesforce permission model.

Document the objects, fields, records, actions, and external systems the agent requires. Then test those permissions under realistic user and customer scenarios. The Trust Layer’s secure data retrieval preserves Salesforce access controls for grounding.

“What data is sent to the model?”

Document the exact architecture.

Which Salesforce feature is being used? Which model provider is involved? Is the model inside or outside the Salesforce trust boundary? Does the interaction pass through the Trust Layer?

“Does the model retain our data?”

For supported external model providers operating through the Trust Layer, Salesforce documents zero-data-retention arrangements under which data sent from Salesforce is not retained or used for provider training after the response is returned.

With that said, that answer should still be tied to the specific implementation rather than generalized across every AI integration in the enterprise.

“How do you prevent the agent from doing something it shouldn’t?”

This is where permissions, topics, instructions, actions, guardrails, and escalation rules come together. You should be able to explain not only what an agent can do, but under what conditions it can do it.

“Can you show us what happened?”

Audit trails are the answer. 

Event-level information, output evaluation, metadata, audit trails, reports, and alerts can help administrators identify patterns such as repeated ungrounded responses. Salesforce’s current documentation similarly describes audit and feedback capabilities that log prompts, responses, and trust signals in Data 360.

“What happens when the agent gets it wrong?”

It helps no one to reply that the model will improve. 

The journey should have defined escalation points, human review, rollback or correction procedures where relevant, and monitoring for recurring failure modes. 

The Trust Layer can provide visibility into the interaction. Agentforce guardrails can evaluate behavior against configured instructions. The business still has to decide what happens when a control is triggered.

We want to emphasize that AI governance in financial services does not start and end with the model. It extends into the data foundation. That includes data classification, ownership, access controls, retention, consent, legal basis, and privacy-by-design principles. If customer data is poorly classified, permissions are too broad, retention policies are unclear, or consent information is disconnected from the customer record, adding an agent doesn’t solve any of these issues. That’s why, agentic implementation should correspond with your organization’s data governance model.

How to start with human-reviewed AI agent journeys

The most practical starting point is arguably controlled autonomy. 

Begin with a journey where the value is measurable and the consequences of an incorrect action are manageable.

An agent might:

• retrieve and summarize customer context
• answer straightforward status questions
• prepare a recommended next step
• draft a customer communication
• identify information that needs attention
• prepare a record update for review

A human can remain responsible for the consequential decision.

It creates a learning loop. The organization can examine where the agent succeeds, where it fails, which instructions create conflicts, where customers need escalation, and which actions should remain human-controlled.

Over time, some of those reviewed journeys can become more autonomous.

Others may remain human-led. 

The aim is knowing, journey by journey, which decisions the organization is prepared to let an agent make, and being able to show why that was the right call.

Looking to adopt or implement Agentforce in fintech? 

Schedule a discovery call with an Agentforce expert.