Your Agent User can see more than you think

Here is the failure everyone hits, in order.

You build an agent in a sandbox. You test it as yourself, because that's the fastest way to iterate, and everything works. You deploy. The agent immediately starts throwing INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, which is a cryptic way of saying it tried to touch something it couldn't reach.

It's 6 pm. There's a demo tomorrow. You give the Agent User "View All Data" and go home.

That fix works, and it's the moment your permission problem stops being an inconvenience and becomes an audit finding. You now have a non-human identity, running unattended, that can read every record in the org.

Why permission models rot

Nobody sets out to build a bad permission model. It degrades through reasonable decisions made under time pressure.

Someone in Support needs access to one custom object. Cloning the existing profile takes 4 minutes; designing a permission set takes an afternoon. So the profile gets cloned. Two years later, there are 9 near-identical profiles and no documentation of the differences.

A sharing rule gets added to unblock a reporting request during a quarter close. It's still there. The report is not.

A permission set assigned for a 6-week migration project in 2021 is still assigned to 14 people, three of whom have changed roles twice since.

None of this causes visible problems, because of one fact about human users: they don't test the boundaries. A rep in Manufacturing has technical read access to Contracts through a role hierarchy path nobody remembers building. She's never looked, because Contracts aren't part of her job and there's no link to them on her page layouts.

The access is real. The exposure is theoretical. Everybody moves on.

What changes with an agent

An Agentforce agent runs as a dedicated Agent User with its own profile and permission sets. That user needs access to every object, field, and record that any action in any topic might touch. Miss one and you get the cross-reference error. Over-grant and you have created something new in your org: an identity that will actually use everything it's been given.

Three things make this different from a human user.

It has no page layouts. A human's practical access is bounded by the UI they see. An agent calls actions directly, so the boundary is the permission model and nothing else.

It traverses relationships without noticing. Your action queries Contacts. The Contact has a lookup to Account. The Account has a formula field referencing a custom Product object. The agent's query walks all of it. Any gap in the chain fails the whole transaction, and any excess in the chain is exposure.

It runs unattended, at volume. A human doing something they shouldn't leaves a trail somebody eventually notices. An agent doing it 400 times before lunch leaves a very clear trail, and by then it's an incident report.

There's a version of this in every system of record. In ServiceNow it's elevated roles and ACL inheritance, where a script running with elevated privilege reaches past what the role that triggered it should permit. Same shape, different vocabulary.

Assigned access and effective access

The gap that matters is between what a profile says a user can do and what that user can actually reach.

Assigned access is readable. It's in Setup. You can screenshot it for an auditor.

Effective access is the composition of profile, permission sets, permission set groups, role hierarchy, ownership, sharing rules, manual shares, territory assignment, and every lookup and formula path that pulls a related record into scope. It's the number that matters and it's the one nobody has.

Working it out by hand for a single user takes a skilled admin the better part of a day. Doing it for a proposed Agent User across every action in every topic, before deployment, is not something a team does manually. Which is why it doesn't get done, and why the 6pm fix keeps happening.

Finding the gaps first

Tribal computes effective access. For any user or Agent User, it resolves the full composition and returns what that identity can genuinely reach, which in most orgs runs well past what the profile suggests.

That gives you three things worth having before an agent goes live.

A pre-deployment permission map. For each action your agent can invoke, the objects and fields it touches, including everything reached through lookups, formulas, and downstream automation. You see the required access set before you provision anything.

Least privilege by default. When Tribal builds an app or an agent, it provisions to the minimum required set and shows you the delta against what you would have granted manually. The gap is usually large and usually surprising.

The existing mess, quantified. The same analysis run across your current users surfaces the accumulated debt. How many people carry "View All Data" and why. Which permission sets have no clear owner. Which sharing rules grant access nobody has used in 18 months.

That last one tends to be the finding that gets budget approved, because it's the one that reads the same way to your CISO as it does to your platform team.

A short pre-deployment checklist

Before an agent goes to production, get an answer to each of these.

• Every object, field, and record type the Agent User needs, derived from the actions rather than guessed
• Every related object reached through lookup, formula, or downstream automation
• Sharing model reviewed for any object with Private OWD that the agent touches
• Agent User provisioned through a dedicated permission set, with profile permissions kept minimal
• Every action tested while logged in as the Agent User, in a sandbox that mirrors production sharing
• "View All Data" and "Modify All Data" confirmed absent, with a written reason if either is present
• Effective access documented, so the answer exists before someone asks for it

The last line is the one that saves you. Somebody will ask what your agents can reach. Having the answer ready, computed rather than asserted, changes that conversation entirely.

Agentforce is a forcing function here, and that's the good news buried in all of this. The permission debt was always there. Fixing it for your agent fixes it for the 900 humans too.

‍