The first instinct when connecting an agent to Salesforce is to give it room to work. Wide object access, every field, few restrictions. Anything narrower feels like hobbling it before it starts.
Then it answers a question about a renewal by reading a field nobody has maintained since 2023, and states the number with complete confidence.
Two failures, one cause
Broad access fails in two directions at once.
It makes agents confidently wrong. A Salesforce org carries hundreds of fields per object, and nothing in the schema says which are trusted, which are abandoned, or what any of them mean. An agent has no way to tell a maintained health score from a stale one, so it treats them the same. It has no way to know that Type = Partner means reseller in your org and not technology partner. It fills the gap with a reasonable guess, and reasonable guesses are the hardest kind of wrong to catch.
It also makes them quietly unsafe. An agent querying with elevated access returns data the person asking was never entitled to see. The answer looks fine. Nobody notices until someone does.
The usual fixes have their own problems
Hard-coded prompts put the field list and the explanations in the prompt template. They work until the org changes, and then they drift — silently, because nothing fails. Every correction is a deploy.
Broad query access is the situation above.
Bespoke Apex works, and then the next agent needs something slightly different, and you write it again.
All three share a root cause: what an agent should see is a business decision, and it keeps ending up in code.
Curation is not the same as restriction
The alternative isn’t less access. It’s deciding in advance which fields are worth an agent’s attention, writing down what they mean, and letting the query itself enforce who can see what.
Three things change:
- Curated views. A named set of fields that are actually trusted, rather than every field that exists. Usually far shorter than people expect.
- Meaning travels with the value. The explanation of what a field means is delivered alongside it, so the agent doesn’t have to infer.
- Permission-correct by construction. Every query runs as the calling user in user mode, so object permissions, field-level security, and record sharing are enforced by the query rather than applied to the result afterwards. Two people asking the same question get different answers, correctly.
That last point is the one that changes the risk profile. It isn’t a filter someone has to remember to write. It’s the same enforcement Salesforce already applies to a person, applied to the agent acting on their behalf.
Where to start
Pick one object your team asks about constantly. Write down which fields are genuinely trusted, and what each one means to someone who doesn’t work in your org every day.
That list is your first curated view, and it will be shorter than you expect. That’s the point.
