Intapp Celeste for ChatGPT: Test What Happens When Access Is Removed

AI-generated editorial illustration by Viaclause. The people and setting are fictional; this does not depict Intapp or its launch.

A law firm considering Intapp's new Celeste plug-in should ask to see the same question answered by two users with different permissions. Then remove one user's access and repeat the test. That sequence gives a buyer something a successful demonstration alone cannot: evidence about where the answer stops.

Intapp announced the Celeste plug-in for ChatGPT Enterprise on September 17, 2026, with availability starting that day for eligible Celeste clients. The announcement describes business-development and billing work, including checking captured work against outside counsel guidelines. It also says the firm's access restrictions apply to information returned through Celeste. Those are the vendor's claims, not results of a Viaclause product test.

What the announcement changes for a buyer

A firm's information can become useful in a conversational interface while retaining very different access rules for different employees. Our procurement question is therefore specific: can the firm demonstrate that its chosen information boundaries survive retrieval, summarization and a later permission change?

This is analysis of the September 17 announcement, not a new launch on September 27. The public release does not establish how a particular firm's configuration will behave, how quickly permission changes propagate, or what happens to information already present in a conversation. Obtain those answers for the proposed configuration before accepting a pilot.

The broader principle has an established technical basis. NIST's Zero Trust Architecture publication treats authentication and authorization as distinct steps and rejects implicit trust based solely on network location or asset ownership. It is architectural guidance, not a certification of Celeste or a legal opinion about a firm's ethical walls.

A two-user test with a known answer

The following is our proposed acceptance exercise. It has not been run on Celeste. Have the firm's security team and the vendor agree a permitted test environment, the relevant policy and the expected result first. Use synthetic matter records, not client secrets.

1. Build one test matter. Give it a distinctive fictional name and a unique invented fact. Put that fact in a document that one test account may access and the other may not. Record exactly which systems and copies contain it.
2. Establish the allowed result. With the permitted account, request a summary and its source. Check that the expected record, rather than an unrelated document, supplies the answer. A denial for everyone would not demonstrate useful access control.
3. Check the excluded account. Use the same request, then a broader question about the fictional client's relationships or matters. Check the answer, source titles, snippets and links against the agreed policy. A restricted document title can itself reveal information.
4. Revoke the first account's permission. Record the time of the source-system change and the vendor's stated propagation period. Repeat in a fresh conversation and, separately, in the earlier conversation. Treat these as different tests.
5. Inspect the record of the decision. Ask an authorized administrator to identify which account, resource and policy decision were involved. If the available logs cannot establish this, record the evidence gap rather than infer that the system worked.

Separate old output from new retrieval

Suppose the allowed account received the invented fact at 10:00 and lost access at 10:15. Seeing the old 10:00 message at 10:20 does not, by itself, establish that the tool retrieved the document again after revocation. Conversely, a new answer may repeat earlier conversation content without fetching the source.

Keep three observations separate: visibility of stored messages, reuse of earlier conversation content, and new source access. Ask the vendor how each is controlled, retained and logged. Set acceptance criteria for each. Our example describes a test distinction, not observed behavior of the plug-in.

Copy this acceptance record into the pilot brief

• Scope: product version, tenant, connected systems and enabled actions.
• Policy: who may see the matter, its existence, document titles and derived summaries.
• Test: account, synthetic resource, request, expected result and actual result.
• Change: permission removed at what time, expected propagation time, and retest times.
• Evidence: controlled copy of the response, source reference and relevant administrator log.
• Decision: pass, fail or inconclusive; owner, corrective step and retest date.

Agree what prevents expansion before starting. For example, unexplained disclosure of the restricted test fact should hold the affected workflow. Missing logs may leave the result inconclusive. Neither label should be silently converted into a pass to meet a launch date.

Keep access checks separate from the paired AI contract-review tests for answer accuracy and missing clauses.

This exercise covers one access boundary. It does not establish overall security, accuracy, contractual compliance or fitness for every matter. If a pilot can take actions, test its authority to change records separately. For the wider investment decision, connect the pilot to a defined operating objective; if the firm is also evaluating contract analysis, use the separate contract-review evaluation guide.