On a host with QInstance.enforcePermissionsInCoreActions on, a person with
assistant.hasAccess and without assistant.admin was refused before any model
call ("Not authorized to access the assistant admin data."). The assistant
reads its settings (policy, providers, models, prices, budgets, data access)
and writes that person's messages, turns, tool calls, pending actions and
usage through tables whose permission rule is assistant.admin, with the
person's session. On a host without core enforcement nothing checked that
rule for the store, so it was never seen.
AssistantStore, the only package allowed to call QQQ data actions, now marks
every one of its calls as the assistant's own service code
(withPermissionBypass with a reason), the way qbit-collaboration and
qbit-backups do. Only the table permission check is skipped, for those calls:
- the session stays the person's: writes are attributed to them, and the
owner record locks keep every other person's rows out (core does not relax
record locks for a bypass);
- the tables' permission rules are unchanged: the tables stay closed to that
person in the UI, the UI API and the assistant's tools;
- who may call is decided before the store: every operation of the assistant
API requires assistant access, and the save rules of budgets and overrides
require assistant.admin themselves.
A person's own budget. GET /config has "budgets" (UI API extension assistant
1.8.0): the budgets scoped to that user or to a permission that user holds,
with used, limit, percent, state and when the count starts again. Budgets
shared by several people are not listed. The same lines ride beside the
person's question (<assistant_budget>), so "how much of my budget have I
used?" has an answer.
CoreEnforcementTest runs on the fixture instance with core enforcement on.
Run without the store change, four of its five tests failed at the first
store read; the fifth (own budget) was written afterwards.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
james.maesandClaude Fable 5.2