---
title: "What an outside agent can see in your org, and who decides"
url: "https://trailassembly.com/external-agents-and-salesforce-access/"
topic: "Agentforce and AI"
published: "2026-09-10T11:23:12+00:00"
updated: "2026-10-06T13:52:16+00:00"
---

# What an outside agent can see in your org, and who decides

**Short answer:** an agent acting for a user sees exactly what that user sees. Your sharing model is your AI policy, whether or not anybody wrote it down that way. What changes with an agent is not the permission — it is the breadth and the speed. A person opens one record. An agent reads four hundred and summarises them, and nothing in your org treats that as unusual.

## Three layers already decide this, and you configured all of them

Before evaluating any agent, be clear that the answer to “what can it see” is already written in your org.

**Object permissions** decide whether the object is reachable at all — read, create, edit, delete, and the two that ignore everything below them, View All and Modify All.

**Record access** decides which rows. That is the [org-wide default](https://trailassembly.com/org-wide-defaults/) as the floor, then the [role hierarchy](https://trailassembly.com/role-hierarchy/), then [sharing rules](https://trailassembly.com/sharing-rules/), then manual and team shares. Access only ever widens as you go up that stack.

**Field-level security** decides which columns. This is the layer that gets the least attention and matters most here, for a reason worth spelling out.

## The thing that actually changes: breadth

A salesperson opening an opportunity looks at six fields and reads two. An agent asked for a deal health review reads every field it has access to on that record, and on the related records, and it does that for the whole pipeline in one request.

Nothing about that exceeds the user’s permissions. It just uses all of them, at once, for the first time. Three consequences follow.

**Fields nobody looks at become quotable.** Margin, cost basis, an internal risk note, a churn score, the comment somebody typed into a text area in 2021 assuming nobody would read it. If a field is visible to the user and the agent can read it, it can end up in a paraphrase, and a paraphrase travels further than a field does.

**Aggregation defeats the assumption behind field visibility.** “It is fine for them to see this on one record” was often a reasonable judgement. It is a different judgement across every record at once, and it was never actually made.

**Reads look like ordinary traffic.** An agent pulling five hundred records via the API is indistinguishable from an integration doing its job. There is no “unusual for a human” signal, because it is not a human.

## For Salesforce’s own MCP servers, this is already documented

Salesforce publishes hosted MCP servers — [Headless 360](https://developer.salesforce.com/docs/platform/hosted-mcp-servers/guide/headless-360-mcp.html) has been in beta since July 2026, and the access model is written down rather than left to inference.

Two statements from that documentation are the ones to know:

- Every hosted MCP transaction **runs as the authenticated user**, scoped through an External Client App holding the `mcp_api` scope.

- Object permissions, field-level security, [sharing rules](https://trailassembly.com/sharing-rules/), profile permissions and [permission sets](https://trailassembly.com/permission-sets-after-cancellation/) **all apply**. Salesforce’s own wording: if you cannot perform an action in Salesforce, your agent cannot perform it through the MCP server.

So for this path the identity question is settled, and settled the right way. What remains yours is the shape of the access that identity already has, which is the rest of this article.

Two more details worth carrying into a design review. The server exposes a deliberately small tool surface — Headless 360 has four tools, *Discover*, *Describe*, *Dispatch* and *Dispatch Read Only*, over a growing library of operations, so you cannot enumerate agent capability by counting tools. And access can be limited with an **app policy** that pre-authorises only users holding named profiles or permission sets, which is the concrete answer to “who may connect”, and the control to ask for by name.

## As whom does it run? This is the question to insist on

Outside that documented path: a bespoke integration, a middleware connector, a tool somebody wired up with a stored credential: an agent reaching your org authenticates as something, and the choice has consequences you cannot patch later.

**As the named user.** Access is correct by construction. The agent inherits that person’s sharing and field visibility, so nobody sees anything new. Audit records name a real person. The cost is that every user needs the connection, and the agent’s usefulness varies by who is asking, which confuses people.

**As an integration user.** One connection, predictable behaviour, easy to reason about, and it has to be granted enough access to serve everybody, which means the agent can see more than most of its users can. Now the chat surface is your access boundary, and audit trails name the integration rather than the person who asked. This is the option that looks simpler and is not.

My position: named user, and accept the ragged experience, which is the choice Salesforce made for its own hosted servers, and a reasonable signal on its own. If the honest requirement is broad access, that decision deserves a named owner and a written record, not a default chosen because it made the demo work. And if you do go with an integration user, give it its own user with no role, that is the [ownership skew](https://trailassembly.com/salesforce-data-skew/) lesson arriving in a new context.

## The fields to check before you connect anything

Not a full FLS audit. Six categories, and it takes an afternoon:

1. **Money that is not the price.** Cost, margin, discount authority, commission.

2. **Internal opinion.** Risk notes, account health commentary, anything a rep wrote about a customer’s competence.

3. **Scores and predictions.** Churn risk, lead scores, propensity. Quotable, decontextualised, and often wrong in ways only their author understands.

4. **Personal data.** Anything that would matter in a subject access request, and anything you would not want restated in a summary.

5. **Legal and compliance flags.** Litigation holds, dispute status, regulatory markers.

6. **Anything from HR.** If your org holds employee records alongside customer records, check that the wall between them is a real one.

For each: who can read it today, and is that still the answer when it can be read in bulk and restated in prose?

## How you would notice, which is a separate problem

Access review tells you what is possible. Monitoring tells you what happened, and most orgs are weaker here.

Ask three questions of any agent connection. Is each read recorded, and where? Can you attribute a read to the person who asked, rather than to a connection? Would a change in volume (ten times the usual reads, at 3am) reach a human?

If the answers are no, no and no, you do not have an audit story, and that is worth knowing before a security review discovers it for you. Event Monitoring is the platform answer where it is licensed. Where it is not, API usage patterns and login history are the crude substitute.

## The review I would run this week

None of this needs an agent connected, and all of it is worth doing anyway.

- List every profile and permission set with **View All** or **Modify All** on your main objects. That list is usually longer than anyone expects and it is the shortest path to a surprise.

- Pick your five most sensitive fields and get the true read list, permission sets included.

- Count your integration users and check what each one can see. Some of them predate everyone currently employed.

- Write down, in one paragraph, who is allowed to connect an external tool to the org. If the answer is “nobody has said”, that is the finding.

An agent connection is a good forcing function for work that was always overdue. That is the genuinely useful thing about this moment, and it does not depend on which vendor’s agent you end up using.

## Frequently asked

**Does an agent bypass sharing rules?** Not through Salesforce’s hosted MCP servers: the documentation states CRUD, FLS, sharing rules and permission sets all apply, and the transaction runs as the authenticated user. The risk is not bypass, it is breadth, and an integration user with broad access is not a bypass either, it is a grant you made.

**Is field-level security enough on its own?** It controls the read. It does not control what happens to the value after a model has read it, which is why the field list above is a judgement exercise rather than a configuration one.

**Should we block external agents entirely?** You can, through connected app policies, and that position gets harder to hold each quarter. Better to decide who may connect what, and write it down, than to rely on nobody asking.

**Where does this leave prompt injection?** Squarely in scope: a record’s own field content can carry instructions, and an agent reading customer-supplied text is reading untrusted input. That deserves its own article, and it is on the list.

---

Source: https://trailassembly.com/external-agents-and-salesforce-access/
Trail Assembly — independent Salesforce write-ups.