Authority and permissions
Autonomy is grantable when the boundary is explicit. Decide what a run may do before you decide how much it should do.
Every run has an identity, a set of tools it may use, a network boundary, and a list of actions that require a person. Those four together are what make a run something you can leave alone.
| Control | What it decides |
|---|---|
| Run owner | Whose authority the run acts under, and who receives its exceptions |
| Tool allowlist | Which actions the run may perform through its connections |
| Network policy | What the run may reach |
| Approval rights | Which decisions stop the run and come back to a person |
Pause before the consequential action
The useful shape is a run that stops before a consequential action rather than reporting it afterwards. A close date above a threshold, a payment status change, a publish, a merge: each comes back as a question with the evidence attached.
When the run needs a decision, it should ask where the person already is. A question that arrives in the Slack thread the work started in gets answered. A question sitting in a dashboard nobody opened does not.
Correct what the playbook allows. Ask before changing a close date on anything above $50k, and route it to me in the thread with the current and proposed values.
Permissions follow your organization
Advanced controls follow organization roles and product permissions. Someone may be able to read sessions but not start a security sweep, change shared Knowledge, or launch remediation. Confirm the operator and the approval path during planning rather than discovering the boundary mid-run.
Credentials
Do not place readable credentials in a prompt or in working files. Credential values are redacted from agent-visible configuration so that an automation record cannot become a path for distributing secrets.
When a tool requires OAuth, the run pauses and presents the connection step. You complete the sensitive handoff, and the run resumes with the same workspace, evidence, and pending action.