# A lack of authority is not a lack of confidence

Access decisions belong to the application. A model's certainty about an answer must not determine whether the user is allowed to receive its evidence or trigger an action.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Separate permission from answer quality

A user asks for another team's confidential forecast. The assistant might find a highly relevant document and be very certain about the numbers. That does not make the response authorised.

Apply access filtering and object-level checks before restricted information reaches the model or user. Do not retrieve broadly and ask the model to decide whether it should reveal the result.

Use a distinct denial state. Treating the request as low confidence can lead a retry loop to search harder, potentially exposing more information instead of enforcing the boundary.

## Keep denial messages bounded

Explain that the requested information or action is unavailable under the user's access without revealing restricted contents. Even a refusal can disclose information if it confirms sensitive record names, values or relationships unnecessarily.

Provide an approved access-request route where the product has one. Do not promise that access will be granted or invent an approver from retrieved material.

If the user changes the question, evaluate the new request under the same authority model. Rephrasing should not transform a denied target into an allowed one.

## Review stored context and handoffs

A conversation may contain excerpts retrieved while the user previously had access. On resume, decide how current permissions affect rendering and further use of that material.

An escalation is another disclosure path. The recipient must be authorised to inspect the evidence included in the package. Sending the whole conversation to a general support queue can bypass the source permissions even when the initial answer was withheld correctly.

Keep logs and evaluation fixtures within appropriate access and retention rules. Denied requests can still contain sensitive user-supplied information.

## Test certainty against authority

Use a fixture with a clear answer in a restricted document. Ask as an authorised user and an unauthorised user, keeping the question identical. The access decision should differ regardless of how easy the answer is to generate.

Then test direct evidence endpoints, saved conversations and exports. A correct refusal in the main chat does not establish that every supporting route is protected.

Record denial reasons separately from evidence gaps in analytics. This prevents teams from lowering a confidence threshold to solve what is actually an access issue. The assistant's knowledge and the user's authority are different inputs, and the application should preserve that distinction throughout the workflow.

## Sources

- [OWASP: authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [Microsoft Learn: search security filters](https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search)