There is a tempting shortcut in agent design: let the model see everything, then filter the output. It is easier to build, it demos well, and it is structurally unsafe.
The post-filter problem
If a model has board-level revenue figures in its context and you filter the response afterwards, three things can still go wrong:
- The model paraphrases a restricted number into an unrestricted-looking sentence
- The model reasons from restricted data to a conclusion that leaks its substance
- The restricted data sits in logs, traces, and provider-side retention regardless of what the user saw
Output filtering is a content moderation technique applied to an access control problem. The two are not interchangeable.
Scopes as the enforcement point
The alternative is to resolve permissions before composition. When an agent asks a question, the sequence is:
- Identify the caller — user, agent, or workflow — via your existing identity provider
- Resolve which scope applies to that caller
- Match the query intent against knowledge items within that scope only
- Compose the context package from the permitted subset
- Send to the model
Restricted knowledge never enters step four. There is nothing to filter afterwards because there is nothing there.
Identity-aligned, never elevated
A principle we hold to: the agent's effective permissions never exceed those of the human it acts for. If a support rep cannot see churn cohorts in your BI tool, the agent answering on their behalf cannot see them either.
This sounds obvious and is routinely violated. Service accounts with broad warehouse access are the default in most integrations, and an agent inheriting one becomes a privilege escalation path with a chat interface.
Design rule: map scopes to the roles that already exist in your identity provider. If you find yourself creating a new permission model just for agents, you have probably built a way around your existing one.
The audit trail this produces
Enforcing at the context layer has a useful side effect: every delivery is a discrete, loggable event. Who asked, what scope resolved, which items were served, which were withheld, and when. That record is far more meaningful than a transcript of model outputs, because it describes the boundary rather than the conversation.
When a security review asks "could the support bot have seen the board figures", the answer is a query against that log, not an argument about prompt engineering.
