What the assistant may do
Four switches, all off, what each one unlocks, and where the gate actually sits.
The assistant can read what you can read, because it asks through your own session. What it may do is four separate switches, and every one of them starts off.
They live in settings, under the assistant panel, and they belong to your profile rather than to the machine, so they follow your account.
| Switch | What it unlocks |
|---|---|
| Apply changes without asking | A proposed change is written the moment it is proposed, with no Apply button |
| Read page errors | Uncaught errors and rejected promises on the ServiceNow page, with their stacks |
| Run JavaScript in the page | Code in the page: the form API, Ajax calls, the DOM, in your session |
| Run background scripts | Server-side script with your rights, through the background script page |
The one that deserves a second thought
Apply changes without asking does more than remove a click: it also skips the update set guard. A change applied that way can land in Default, where it cannot be migrated. It is the only switch here that can cost you work rather than exposure, which is why the guard is named in its own description rather than left as a footnote.
Read page errors records uncaught errors and rejected promises. It deliberately does not record
console.log lines, which is where people print values while debugging.
Where the gate is
Three of the four map to a tool the model can call, and the check sits in the one place that dispatches every tool, not inside each tool's own implementation. The reason is simple: a capability whose own implementation decides whether it is allowed is a capability that becomes allowed the day somebody edits it.
The fourth, applying without asking, gates the write path rather than a tool.
The switches are read live on every call, never captured when the panel mounts, so turning one off takes effect on your next question rather than on your next reload.
Refusals are told to the model
When a tool is not allowed, the refusal names the switch and where to find it, and tells the model not to try again. The list of denied tools also travels with a multi-step run, so the model plans with what it actually has instead of proposing a route it cannot walk.
The default is load-bearing
Every other preference in the widget defaults to on and is read as "not the string false". These four are read as "the string true", precisely so that a permission written in the other style cannot arrive on a machine that has never heard of it and be treated as granted.
For the same reason a profile that predates these switches is left alone rather than having a refusal written into it. Not answered and answered no are different states, and a sync must not invent an answer you never gave.