Start with four separate responsibilities
- Salesforce session holder: the browser extension or approved client that already has the signed-in session.
- Salesforce tool executor: the local component that performs allowlisted API requests and returns bounded results.
- AI transport: the backend that authenticates the product account, applies limits, and calls the configured AI service.
- Human decision maker: the user who chooses context, presses Send, reviews output, and confirms consequential actions.
Combining these responsibilities into one opaque request makes it difficult to prove where credentials travel, which data the model saw, and who authorized an action.
Keep credentials out of the chat payload
Salesforce session IDs, access tokens, cookies, authorization headers, connected-app secrets, and refresh tokens are capabilities, not context. The model does not need them to explain a permission path, summarize a schema, or reason over a query result.
A backend log, analytics event, error report, or model tool argument is still a transmission path. Credential exclusion must happen before every backend and model boundary, not only in the visible chat text.
Send bounded business context
Useful context may include the user's question, selected object and field definitions, a small set of relevant metadata matches, compact org facts, current page purpose, and a bounded page of tool results. The product should make the selection visible and allow the user to remove it.
Use minimization twice: first select only the sources relevant to the task, then reduce each result to the fields and rows needed for the answer. Pagination should require an explicit next request rather than silently sending an entire org inventory.
Keep execution and confirmation outside the model
The AI may recommend a query, explain a difference, or propose a change. The product should still validate the request, show the exact operation, apply existing permission checks, and wait for user confirmation in the authoritative workspace.
This keeps the model advisory. It also preserves familiar audit evidence: who initiated the action, which org received it, what changed, which checks ran, and what the result was.
Architecture review checklist
- Can you list every network destination for Salesforce data, identity data, prompts, and tool results?
- Are session credentials excluded before backend, log, telemetry, and model boundaries?
- Can the user see and remove selected context before Send?
- Are tool schemas, result sizes, page counts, and function calls bounded?
- Do write, deploy, delete, Apex, and other consequential actions retain product-side validation and confirmation?
- Are local tests, live backend readiness, billing readiness, store approval, and customer-org validation reported separately?
How Dina Agent applies the model
Dina Agent for Salesforce 0.5.0 runs Salesforce tools inside the Chrome extension, excludes Salesforce credentials from AI chat requests, sends bounded context only after the user presses Send, and keeps the AI panel advisory. It is still a development preview: this architecture and local validation do not establish live production, billing, store, or customer-org readiness.