THE KEY ANSWER
Permissions must be checked before retrieving and passing data to the model, as well as before every operation. Control must cover documents, history, cache, and exports. Hiding the link to the source after a response does not secure the content.
Define access for specific objects
Start with a matrix of roles and data. Who can read a document, who can change its status, and who can approve the result? Consider the department, client, project, and confidentiality level if they affect the process. The role "employee" alone is often too broad for information about contracts or other clients' data.
Demonstration example: a consultant has access to cases assigned to their team, but not to all company-wide tickets. The assistant should search within the same scope. A global technical account facilitates system integration but cannot automatically determine the access of the person asking the question. Passing and verifying the user's identity is required.
Context and references: OWASP: Authorization Cheat Sheet
Control does not end with search
Results may be saved in history, a buffer, or a file for download. Check whether subsequent users receive a response prepared earlier for a broader scope of permissions. The cache key and sharing policy should consider access boundaries, not just question similarity.
Plan for role changes and employee departures. Revoking permissions at the source should affect related copies and future responses. Some organizations require retaining history within a specific scope; such rules must be agreed upon with the data owner. The technical implementation must enforce the actual policy, not guess it.
Read and action are different permissions
The ability to view an order does not imply the right to cancel it. Tools performing changes should check the type of operation, the object, and the current state. It is not enough to confirm that the user is logged in. Between preparing a proposal and executing it, the status of the case or the user's role may change.
Upon acceptance, display the scope of action and relevant data. Verify these again on the server side. The model should not independently set access boundaries based on what someone wrote in the conversation. The declaration "I am an administrator" is content to be read, not proof of permission.
Acceptance requires cross-role testing
Create test accounts with different scopes. Ask about the same document, use history and export, and then revoke access. Also check links opened directly, outside the interface. A hidden button is not a security measure if the operation can still be performed via a request.
In the event log, record identity, operation type, and control result, limiting unnecessary content. Determine who can view such a log. Logs are also a dataset and should not accidentally become a place of broader access than the product itself. Repeat verification after integration and permission model changes.
WHERE TO START
Bring this into your project.
- Define roles, objects, and operation types.
- Consider history, export, and cache.
- Re-check access when executing a change.
- Test permission revocation and accounts for different clients.
Choose one thing your process is missing today. It's a useful topic for your first conversation with the team.
QUESTIONS AND ANSWERS
Frequently asked questions.
Can you instruct the model to monitor access?
You can describe the expected behavior, but the application must enforce the access decision. The model should not receive data that the user cannot see.
Does a private deployment solve the problem?
It changes the hosting method but does not replace permissions within the organization. You still need to separate roles, clients, projects, and operations, and control history and logs.
Sources and context
- OWASP: Authorization Cheat Sheet ↗
OWASP describes the design and verification of authorization. The scenarios above transfer this problem to the history and workflows of a corporate assistant.
Prepared by the ALGOV team. Current as of September 8, 2026. Examples describe possible scenarios, not results from client projects. How we create our guides.
