Every AI tool pitch now includes the same sentence: it respects your existing permissions. Sometimes that’s true. The question is how, and whether you can see it for yourself.
Law firms have the sharpest version of this problem. An ethical wall (a screen) is an access-control decision: certain people must not be able to see certain matters, and the document management system enforces it. The moment an AI assistant can retrieve and summarize across the repository, the wall is only as good as the connector’s answer to one question: does the assistant see what the signed-in user sees, or what the assistant’s own credentials see?
The same question exists outside law. A grant evaluator who may see aggregates but not individual students. A regional manager who may see her region’s payroll but not the company’s. A board member who may see the financials but not HR. The rule is always configured somewhere. The risk is that the AI layer quietly reads around it.
The four places a wall fails
Permission problems in AI systems rarely show up as a dramatic breach. They show up as a correct-sounding answer that the user had no right to receive. There are four points where that happens.
Retrieval. The assistant goes to fetch documents. If it authenticates as the user, it gets what the user gets. If it authenticates with a service account or an admin token “for convenience,” it gets everything, and the filtering, if any, happens afterward in code someone wrote under deadline.
Indexing. Many tools build a search index or embeddings ahead of time so answers are fast. Ask who the index was built as. An index built with broad credentials and queried with narrow ones is a wall with a tunnel under it: the restricted content is already in the index, and whether it leaks depends on a filter applied at query time.
Processing. Once content leaves the system of record and enters a model, where does it go? Which vendor, which sub-processor, which region, and is any of it retained or used for training? A screen that holds inside the DMS means little if the processing path stores prompts and outputs somewhere the screen doesn’t reach.
Output. The subtlest failure. An assistant can decline to retrieve a document and still reveal it, by quoting from a summary it generated earlier for someone else, by answering a question whose answer only exists in a restricted file, or by listing matters the user should not know exist. Output is where “it respects permissions” needs to be tested, not read off a datasheet.
Two architectures, one honest question
Strip away product names and there are two ways to connect an assistant to confidential records.
In the first, the assistant has its own identity: an API key, a service account, an integration user. It reads broadly and relies on downstream logic to decide what each person may see. This is fast to build and easy to demo. It is also a side door, and every filter in it is a thing that can be misconfigured.
In the second, the assistant has no identity of its own. Each request runs on the signed-in user’s credentials, the system of record applies the same permissions it always has, and the assistant can only summarize what came back. This is how the better connector standards work now, including Model Context Protocol connectors that run on each user’s own login. It is slower to set up and harder to demo. It is also the only one of the two where the wall is enforced by the system that owns it.
When you evaluate a tool, the honest question is simply: which one is this? Vendors will not always volunteer the answer, and sales material tends to describe the second while the integration ships the first.
What I learned building one
In 2026 I added an AI connector to a student-success platform I built for Miami Dade College’s STEM PACTS program. The data is FERPA-protected, and the program’s external evaluators, staff, and administrators each have different rights. I was not willing to ship a connector that gave an assistant more than the person asking had.
Four decisions made it hold:
- The assistant inherits the user’s permissions, never its own. There is no connector account. Every request carries a specific person’s credential, and the platform applies the same scope it applies in the browser.
- Scope is tiered and explicit. Aggregates only; individual records; ad-hoc query. A person sits in one tier, and the assistant cannot climb.
- Every query is logged to a person. Not to “the AI integration.” An evaluator can see who asked what, and when.
- Leaked credentials are refused. A higher-privilege credential that shows up in a URL, a screenshot, or a shared screen is rejected rather than honored, because a credential that leaks is no longer that person’s.
The part that matters for anyone evaluating a tool: this is testable in an afternoon. Create two users in different permission groups on synthetic data. Have each ask the assistant for something only the other may see. Then ask the questions that attack output rather than retrieval: summarize everything about X, which matters mention Y, what did the assistant tell my colleague about Z. The wall either holds in the transcript or it doesn’t.
Why this is a gate, not a score
Most technology evaluations put governance in a scoring matrix next to cost, features, and user experience, and weight it. That is a mistake. A tool that fails the wall test is not “weaker on governance.” It is not deployable on confidential records, and no amount of feature strength or price advantage changes that.
So I treat governance as a gate. An option that cannot demonstrate that existing permissions hold through retrieval, indexing, processing, and output does not proceed to scoring until the condition that would fix it is identified and costed. The fix is often real and specific: a higher licensing tier where the user-credentialed connector lives, a configuration change in the system of record, a different processing region. Knowing that cost before the scoring is what makes the comparison honest. A tool that is cheaper only because it skips the gate is not cheaper.
For lawyers specifically
None of this changes a lawyer’s obligations. ABA Formal Opinion 512 (2024) and The Florida Bar’s Ethics Opinion 24-1 (2024) both walk through generative AI in terms of duties that already existed: competence, confidentiality, supervision, candor about fees. What is new is that a question a firm used to answer with a file permission now needs a technical answer from a connector.
That split is worth keeping clean. Whether a particular screen is adequate, what consent a client needs, whether a vendor’s terms satisfy the firm’s duties: those are determinations for the firm’s lawyers. Whether the connector actually enforces the screen through all four stages: that is a technical finding, and it should be delivered to the lawyers as an input, with the evidence attached, rather than asserted by the vendor or the consultant.
Five questions to ask any vendor
- Does the assistant retrieve content as the signed-in user, or with its own credentials? If its own, where is the filtering, and who can change it?
- Is there a pre-built index or embedding store? Built under whose credentials, and how is it filtered at query time?
- Where are prompts, retrieved content, and outputs processed and retained? By whom, for how long, and is any of it used to train or improve a model?
- Can the assistant reveal, in output, the existence or contents of a record the user cannot open? Show me the test, not the policy.
- Can we run this on a sandbox with synthetic data and two users before we buy? If the answer is no, treat every permissions claim as unverified.
Before you compare prices, run the test. The answer decides what you are actually comparing.