Autonomy is not one setting
Most teams talk about AI autonomy as a single switch: either a person checks the work, or the system runs on its own. That framing hides the actual design problem. An AI workflow's exposure comes from three separate dials, not one.
The OWASP GenAI Security Project describes this directly in its guidance on excessive agency in LLM applications: systems get into trouble through excessive functionality, excessive permissions, and excessive autonomy, often in combination. A workflow can have a tightly scoped tool but too much standing permission, or the right permission but no approval gate before it acts. Each dial has to be set on its own.
Functionality: give the workflow fewer tools than it could use
It is common to hand an AI workflow a general-purpose capability, such as a database query tool or a broad API client, because it is convenient to build once. That convenience is the risk. A tool that can do more than the workflow needs is a tool that can be misused by a bad output, a manipulated input, or a model that reasons incorrectly about a single case.
The safer pattern is to build narrow, named actions: 'update ticket status,' not 'run arbitrary API call.' Each action should map to one operational step, so the blast radius of a mistake is the size of that step, not the size of the entire integration.
- Name each tool after the specific action it performs.
- Reject open-ended actions such as free-form shell, SQL, or file access.
- Review the tool list the same way you would review a new employee's system access.
Permissions: scope access to the workflow, not the platform
A workflow's credentials often inherit whatever access was convenient to provision, which is usually broader than the task requires. If a workflow only needs to read claims and write approval status, it should not also be able to write to unrelated tables or call unrelated services.
Treat the workflow as its own identity with its own least-privilege access, separate from the engineer who built it and separate from any end user it acts on behalf of. Rotate and audit that access on the same schedule as any other service account, not as an afterthought once the pilot works.
Autonomy: decide which actions require a person first
Autonomy is the dial most businesses skip designing on purpose. The default becomes whatever the first prototype happened to do, rather than a decision about which actions are reversible and low-stakes versus irreversible and high-stakes.
OWASP's guidance is specific here: implement human-in-the-loop control so a person approves high-impact actions before they execute, rather than reviewing them after the fact. Drafting a response, flagging a case, or proposing a reclassification can usually run unattended. Issuing a refund, closing an account, or writing to a system of record usually should not, until the workflow has a track record that justifies loosening that gate.
Validate the action, not just the intent
The last piece is what OWASP calls complete mediation: every downstream request the workflow makes should be checked against policy at the point of execution, not approved once because the model's stated plan sounded reasonable. A model can describe an appropriate action and then call a different one, and a workflow that trusts the description instead of validating the call inherits that gap.
In practice this means the business rule lives outside the model, in code or configuration the model cannot rewrite: allowed value ranges, required approvals for amounts above a threshold, and hard stops for actions the workflow should never take regardless of what it was asked to do.
Make the controls visible to the people who own the risk
None of this needs to live only in engineering documentation. The functionality list, the permission scope, and the approval thresholds are business decisions, and the operations leader accountable for the process should be able to see and sign off on all three before a workflow goes live.
Revisit the same three dials whenever the workflow's scope changes. Adding one new tool or one new write permission is a small pull request, but it is also a new autonomy decision, and it deserves the same deliberate review the first version got.