Connecting an assistant to firm data changes the scope of the system. The review needs to follow the information from its source through retrieval, processing, storage, and output. It also needs to explain whose access the assistant is using. I want those paths to be visible before a convenient interface becomes part of the firm’s daily work.
Source
Identity is becoming a central part of the agent discussion
NIST’s August 2026 analysis discusses scoped authorization, credential practices, and consent fatigue. It suggests that repeated approval prompts are an incomplete answer to a poorly bounded connection.
I would define the assistant’s permitted job and information path before choosing where approvals belong. Put human attention at consequential decisions and use enforceable controls for the ordinary boundary. Then test whether access changes behave as expected.
Proposal
Follow every copy
Start at the source system and follow the path through connector, index, model processing, retained history, and output destination. Determine which components store copies and which retrieve information only when needed.
Describe this figure
Six stages from left to right, joined by the data's path: source system, connector, index, model processing, retained history, and output destination. Under each stage the review answers two questions. First, does the stage store a copy or retrieve information only when needed? The source holds the original; the output holds a summary that can carry sensitive information; the connector, index, model processing, and history are left open, to ask the provider or test. A deletion in the source may not immediately remove every derived copy. Second, whose authority does the stage use: the current user's permissions, a shared service identity, or a combination? The source enforces its own permissions and the output destination has its own access rules; the other four stages are left open. A person who cannot access a document directly should not receive its contents through the assistant.
A deletion in the source may not immediately remove every derived copy. The review should establish the actual behavior of the selected products, including retention settings, indexing delays, and any supported deletion process. Keep unanswered questions visible until the provider or a controlled test resolves them.
The same mapping should cover where generated summaries go. A summary can contain sensitive information even when it looks like a new document. Its destination and access rules deserve the same attention as the source.
Identify whose authority is being used
An assistant may operate with the current user’s permissions, a shared service identity, or a combination. Describe that model precisely. A broad connector account can create a larger exposure than the individual user’s ordinary access suggests.
Verify permission enforcement with appropriate test identities. A person who cannot access a document directly should not receive its contents through the assistant. Test both the initial permission and a later removal of that permission, including any relevant cache or index behavior.
OWASP’s excessive-agency guidance is useful here because it separates functionality, permissions, and autonomy. Review all three. A read-only connector with overly broad visibility still presents a problem, and a narrowly scoped connector can still have an unnecessarily powerful action.
Treat retrieved content as data
A document or web page can contain instructions that appear to address the assistant. The workflow should preserve the distinction between source material and the authority granted by the user or application.
Include adversarial examples in a bounded evaluation. For example, a test document could ask the assistant to ignore its task or send information to an unrelated destination. The expected behavior is to continue respecting the authorized task and access boundaries.
NIST’s Generative AI Profile provides a broader foundation for evaluating risks in context. No single test proves that every malicious instruction will be resisted; use layered controls that limit the consequence of a failure.
Make the connection operable
Assign owners for the connector, source permissions, provider settings, and output location. Decide what events are logged without collecting unnecessary sensitive content. Document how to disable the connection and how to address retained information afterward.
Repeat relevant checks when access expands, a source changes, or a product updates its behavior. The initial review is a record of a particular configuration.
The goal is an assistant whose information path can be explained. Before connecting firm data, another operator should be able to identify what it can read, what it can change, which copies remain, and how its access ends.
Proposal
What I would test next
I would begin with one source and two test identities with different permissions. Test initial retrieval, later access removal, and a document containing conflicting instructions. Expand only when the observed behavior supports the proposed boundary.