Q: Who controls access to Copilot?
A: Account administrators and alternative administrators. Copilot is disabled by default. Two enablement steps are required: first, SqlDBM enables Copilot at the account level; then administrators enable it per individual user. Users without admin authorization cannot grant themselves access.
Q: Can Copilot be enabled for specific users rather than the whole organization?
A: Yes. Per-user permissions are live. Administrators can enable Copilot for specific users while leaving it disabled for others. The permission follows the user across every project — no per-project configuration required.
Q: Can we limit how much AI a single user can consume?
A: Per-user daily credit limits are planned for a future release. Administrators will be able to assign a daily consumption cap per user. When a user hits their daily limit, they stop consuming credits for the remainder of the day even if the shared pool has balance. Limits reset automatically the next day. Availability dates are TBD — contact your account team for the latest roadmap status.
Q: Does Copilot inherit the user’s existing SqlDBM permissions?
A: Yes. Copilot operates within the user’s existing permission scope. A read-only user cannot make changes via Copilot that exceed their existing privileges. The AI does not escalate permissions — it proposes changes that the user must have rights to commit.
Q: Can read-only users ask questions without being able to make changes?
A: A read-only Copilot mode — where the AI can explain and answer questions but cannot propose model changes — is planned. Availability dates are TBD. Until it ships, the recommended approach is to enable Copilot only for users whose existing SqlDBM role allows modification.
Q: Does Copilot ask for confirmation before applying changes?
A: Yes. Every AI-generated change is proposed, not executed. Users review the proposed change and approve it before any modification is applied to the model. The AI does not act autonomously.