Turn on the lowest consequence feature first: read-only scheduled summaries, then file generation with restricted sharing, then the desktop app with scoped permissions, and the remote sandbox last or in parallel for isolated work. Move to the next step only when the previous one has logs, owners and a tested off switch.
Why order matters
Each feature widens what the assistant can do without a person watching. OWASP names excessive functionality, permissions and autonomy as the root of excessive agency, so a sensible rollout adds one of those at a time and watches. Turning everything on at once makes it impossible to tell which change caused a problem.
A suggested order
| Step | Feature | Scope | Exit criteria |
|---|---|---|---|
| 1 | Scheduled tasks, read only | Summaries and digests for one team | Failure alerts tested, logs exportable, owner named |
| 2 | File generation | Plain documents, no macros, private links | Retention known, admin delete tested, formulas checked |
| 3 | Desktop app | Pilot group, scoped folders, enforced settings | Permission tests passed, update ring in place |
| 4 | Remote sandbox | Fresh per task, restricted network | Egress tested, secrets short lived, state policy set |
| 5 | Scheduled tasks that write or send | Approved task types with approval steps | A month of clean logs, rollback plan |
Step four can run alongside step three if a team needs it, but keep it behind its own approval.
Pick pilot groups with care
Choose people who will report problems, not just use the tool. A mixed group helps: one developer, one analyst, one person from a business function. Avoid starting with teams that hold the most sensitive data. Rotate in higher sensitivity teams once controls are proven.
What to have before each step
- A named owner who can answer for the feature
- An org wide switch you have tested
- A log source you have checked
- A short rule for staff: what to use it for and what not to put into it
- A way to hear about problems quickly, such as a chat channel
If one is missing, finish it before the step.
Gate the risky parts
Anything that sends, deletes, pays or changes shared records should require approval at first, however confident the team feels. Relax this per action type after you have seen a clean period, not before. Keep the approval log; it becomes useful evidence later.
Review every month
After each step, hold a short review: incidents, near misses, surprising behavior, new vendor changes. Vendors add capabilities through updates, so the feature you approved in October may not be the one running in January. Re-test the controls that matter after major releases.
When to stop
If a step turns up a gate failure, such as no way to disable the feature or missing logs, pause the rollout of that feature and keep the others running. Escalate to the vendor in writing.
Safeguard offers policies, gates and an MCP Guardrail for the security tooling side of agent access, and you can run a free scan at gold.safeguard.sh/scan to see your dependency baseline before automation touches it.
A worked example: a ninety day plan
A 400 person company applies the order over about three months.
Weeks 1 to 3, scheduled read only tasks. Three teams create digests: open pull requests, new advisories and stale access grants. The security team reviews each task with the ten questions. Failure alerts are tested by revoking a test token. Logs are exported once to check the format.
Weeks 4 to 6, file generation. The company enables plain documents and PDFs for the pilot teams. Macro formats are disabled. Links are set to organization only. The admin deletes a test file to confirm the path works. A rule is published: customer data stays in company storage.
Weeks 7 to 10, desktop app. Twenty developers get the desktop app with managed settings. Folder scope, clipboard and commands are locked. An update ring starts with five volunteers.
Weeks 11 to 13, remote sandbox. One team starts using a remote sandbox for triaging public issues, with a fresh environment per task and an allowlist. A near miss, where a task tried to reach an unlisted host, is logged and reviewed.
At the end the company reviews all four, adds approval steps for write tasks and sets a monthly review.
Step by step: run your own steps
- Write the exit criteria for each step in advance.
- Name the owner and the pilot group.
- Test the off switch before enabling for users.
- Enable for the pilot only.
- Collect logs and feedback for a fixed period.
- Hold a review against the exit criteria.
- Decide: proceed, extend, or pause.
| Review question | Evidence |
|---|---|
| Did alerts reach a person? | Test records |
| Were there surprises in logs? | Review notes |
| Did anyone work around the rules? | Feedback and logs |
| Did the vendor change something? | Release notes |
Handling pressure to go faster
Leaders may want everything on at once. The answer is to show the order and its reasons, and to point out that exit criteria can be met quickly if the work is prepared in advance. A team that has the forms, tests and owners ready can finish a step in days. The order is about visibility, not about delay.
What if a step uncovers a problem
Pause only that feature. Tell the pilot group plainly, fix or get the vendor to fix the gap in writing, and resume once the criterion is met. A visible pause builds trust in the process.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate stops a change until a rule passes, the same idea as approval steps in a rollout.
Quick check
Is it wrong to start with the desktop app?
Not wrong, but it gives the assistant more reach on day one. If you do, scope folders tightly and keep command approval on.
How long should each step last?
Long enough to gather a few weeks of logs and one real incident drill. Let the exit criteria decide, not the calendar.
Should we publish the order to staff?
A short note helps. It explains what is available now, what is coming and why, which reduces unofficial workarounds.
Sources
Last reviewed: 19 October 2026.
