A sales rep and a finance analyst each ask the same agent about the same Opportunity. Same tool. Same record. Same question.
The rep’s payload has the deal fields, the contact roles, the next step and the health signal. The analyst’s payload is built around margin, discount approvals and the terms that matter to Finance. Neither user was configured. Nobody wrote a rule for either of them.
Two things decided what each of them got, and they are different things. The domain shaped the context. Permissions enforced security.
The domain shapes the context
A domain is a named set of context that an agent asks for by name: the entities it can read, the briefs that explain the business, and the skills it can run. The people who know the business compose it.
The Sales domain’s primary view of an Opportunity is the deal view. It carries the fields a rep acts on, the instruction that explains what each one means on the sales floor, and the briefs about how this team sells. The Finance domain’s primary view of the same object is the finance view. It carries margin and discount approval history, read through Finance’s own instruction. One record, two readings, each composed by the team that owns that reading.
That is shaping, not security. A domain decides what an agent asks for and how it reads what comes back. It widens what the agent may ask for. It never widens what the user may see.
Permissions enforce security
Every request runs as the user asking. The query that assembles the entity is subject to that user’s field-level security and sharing rules, the same ones Salesforce already enforces everywhere else.
The common alternative is to fetch broadly and trim before display: run the query as an integration user, get everything, then remove what the caller should not see. The problem is the middle step. The model already saw the data, and the filter is code someone wrote and someone can forget to update when a new field is added.
ContextWorks has no middle step. There is no code path where a value is fetched and then hidden, so there is no code path where hiding can be forgotten. That one sentence is usually what gets a security review to yes.
The same rule holds for computed values. When an Apex provider returns a list of related records, ContextWorks keeps only the IDs, re-queries them as the calling user, and renders them through the target entity. Only constructed scalars, like a score, are trusted as given, because arithmetic has nothing to re-check against.
And nothing leaves. No copy, no sync, no index, no vector store. The data stays in Salesforce, which already has the permission model, so there is no second security model to reconcile and no staleness window.
Put the two together
Give the rep the Finance domain. The agent now asks for margin, because the domain tells it to. Margin still does not appear, because the rep’s permissions do not allow it. The shape widened. The ceiling held.
That is the whole line in one move. The person composing a domain, a RevOps lead or a sales ops analyst, controls what is in the context. They never control who may see it. The worst outcome available to them is composing something useless. They cannot leak data, because they are not in the path that decides visibility.
That is what lets the people who know the business own the definitions, and lets security know that users and AI toolse are restricted by the same existing roles and permissions.
