Autonomy in autobotAI is never the absence of governance. It is governance set in advance, in the scope, limits and reversibility of each action, and checked continuously afterwards.
You decide how much each action may do on its own. The decision is made per action and by risk, not by how confident a model is, and never by the AI itself.
Autonomy tiers
| Tier | Name | What happens | Typical use |
|---|---|---|---|
| A0 | Advisory | The agent investigates and recommends. Nothing changes without a person. | Enrichment, summaries, investigation reports |
| A1 | Gated action | The agent prepares the change; an approval node holds it until a named approver decides. | Disabling an account, merging a fix, changing a firewall rule |
| A2 | Bounded autonomy | The agent acts on its own inside a pre-approved envelope: scoped, capped and reversible. People are notified and can override or revoke. | Revoking an expired temporary grant, quarantining a confirmed phishing email |
| A3 | Constrained by design | The capability is removed at the credential or architecture level, so no agent can exceed it, however it is instructed. | Forensics agents that cannot write, read-only agents in regulated scopes |
Most teams start new agents at A0 or A1 and move an action to A2 only after its record shows it's safe.
How an action's tier is set
Each action is classified by what could go wrong if it were wrong:
- Reversibility: can it be undone quickly and completely?
- Blast radius: how many users, systems or customers would it touch?
- Sensitivity: does it involve production, regulated data or privileged identities?
- External effect: does it reach customers, partners or the public?
- Cost to recover: what would fixing a wrong action take?
The higher the stakes, the lower the autonomy. Some actions, such as anything that could destroy evidence, are always A3.
Approvals
When a workflow reaches an approval node, it pauses and sends the request to the approvers named in the node.
- Where approvers decide: Slack, Microsoft Teams, Google Chat, email (including Amazon SES), Jira, or a pull request in your code repository.
- What they see: a summary of what happened, the evidence and execution logs, the proposed change and similar past cases.
- What they can do: approve, reject, change the proposed response, or ask for more information.
Approvers can also act from the Approvals page in the app. See Approvals.
Fixes arrive ready to approve
Agents don't hand your team a PDF. They draft the change in the form your team already reviews:
| Layer | What the agent prepares | Who decides |
|---|---|---|
| Application code | A pull request with the proposed fix | The owning developers |
| Web application firewall | A WAF rule, deployed in count mode first, moved to block once logs confirm it's safe | Security or platform owners |
| Network | A firewall or security group change | Network owners |
| Cloud posture | A configuration change routed to CloudOps | CloudOps |
| Dependencies | An upgrade applied in a lower environment first | Release owners |
Follow-through and proof
- SLAs. Each finding carries a due date. Agents follow up with the owner and escalate to the next approver when it slips.
- Exceptions. If an owner can't fix in time, they can request a risk acceptance with an expiry, approved like any other decision.
- Re-tests. After a fix ships, an agent re-tests to prove the exposure is gone, and reopens the finding if it isn't.
- Live risk register. Every finding, decision, approver and piece of evidence is recorded as it happens, not compiled at audit time.
Related controls
- Role-based access control: who can build, run, approve and administer.
- Audit trails: the record of every action and decision.
- Responsible AI: the principles behind these controls.