The seven actions an AI agent should never take without a named owner
- Agent permissions are usually granted by integration scope (whatever the OAuth screen offered) instead of business consequence. That is the failure pattern.
- Seven action classes need a named human owner even when execution is fully automated: external communication, public publication, financial commitment, access and permission changes, destructive data actions, production deployment, and legal or policy representation.
- Named ownership does not always mean per-instance approval. Pre-approved bounded execution (thresholds, templates, allowlists) is ownership too, when the owner is named, the bounds are explicit, and the log shows who decided.
- Every red line comes with an emergency stop and an expiry date, so authority stays current and reversible.
- The risk this bounds has a name in the security literature: excessive agency, ranked in OWASP's LLM Top 10, with privilege abuse, unexpected code execution, and rogue agents named in its agentic list.
Watch how an agent actually gets its permissions. Somebody connects an integration, an OAuth screen lists scopes, somebody clicks allow, and from that moment the agent can reach email, files, payments, publishing, code, and customer records. Every grant made sense at the moment of connection. Nobody ever decided, as a business, which consequences the agent may now own. Permission accumulated by integration scope, and consequence never got a vote. Picture where the pattern lands: an agent with mail scope and a customer file drafts and sends a discount offer to the whole list, perfectly inside its technical grants, and the first person to decide anything about it is whoever reads the replies.
The security field has names for where this ends. OWASP's LLM Top 10 (2025) ranks excessive agency (LLM06), meaning systems empowered beyond what anyone actually decided, among the top application risks, and its agentic list (published December 2025) names identity and privilege abuse (ASI03), unexpected code execution (ASI05), and rogue agents (ASI10) among its expert-reviewed risk classes for systems that act. The fix starts with a short list.
The red lines
Seven action classes need a named human owner no matter how automated execution gets: external communication, publication, financial commitment, access changes, destructive data actions, production deployment, and legal representation. Ownership can mean per-instance approval or pre-approved bounds. It can never mean nobody.
The list, and why each line is on it
Two working terms first. Bounded execution means the agent runs free inside limits a named owner set in advance: thresholds, templates, allowlists. Consequence classification means sorting actions by what they can break instead of by which tool performs them. The table applies both.
| Red-line action | What it can break | Bounded execution looks like |
|---|---|---|
| 1. External communication | Customer relationships, at scale, in your name | Approved templates to opted-in recipients; novel messages gate |
| 2. Public publication | Reputation and the record, cached forever | Owner approves artifacts; corrections have their own gate |
| 3. Financial commitment | The ledger, contracts, refunds, purchases | Spending thresholds; above the line, a person decides |
| 4. Access and permission changes | The security boundary itself | No self-granted scope, ever; owner approves each change |
| 5. Destructive data actions | Anything with no undo | Soft-delete by default; hard deletes gate with mandatory delay |
| 6. Production deployment | The systems everything else runs on | Gated pipelines an owner configured; rollback rehearsed |
| 7. Legal or policy representation | Binding positions, compliance exposure | Never bounded away; a person signs, every time |
Two of the seven deserve a word. Access changes (line 4) are the one class where bounded execution barely exists, because an agent that can widen its own permissions can erase every other line on this list; that is identity and privilege abuse, and rogue-agent territory, by name. And legal representation (line 7) is the class I never delegate to bounds at all: when a statement binds the organization, a person makes it.
One more boundary on the list itself. The seven are the common core I find in nearly every organization, and the method underneath is consequence classification. Tailor the classes to your business, add lines your industry demands, and keep the discipline: every consequential class gets a name.
How ownership runs at machine speed
The point of the list is accountability, and accountability survives automation just fine. A named owner can govern a class in two ways. Per-instance approval, through the evidence packets and decision states of an approval map, my process for gating consequential actions before a workflow gets built. Or pre-approved bounded execution: the owner defines thresholds, templates, and allowlists, the agent runs free inside them, and the log still shows who decided, because the bounds themselves are the decision. An outbound email from an approved template runs free because the communications owner approved the template itself. That is ownership operating at machine speed.
The norm has regulatory company at the high-consequence end. US federal policy for high-impact AI requires risk acceptance “supported by a signature from the individual accepting the risk,” and the EU's high-risk rules require override and stop capability. Scope honesty: those bind federal agencies and EU high-risk systems, and the design pattern travels anywhere consequence lives.
Stops, expiry, and the log
An emergency stop. Every class has a way to halt execution now, reachable by the owner, tested before launch. A red line without a stop is a request, and the halt drill belongs in the same test plan as the forbidden-action cases.
Expiry. Bounds age with the business, so every bound and every delegation carries a re-decision date; the approval map covers the mechanics. Authority that never expires becomes authority nobody remembers granting, which is how permission sprawl starts.
The log. Every action in a red-line class records what ran, under which bound or approval, decided by whom. When something goes wrong, the log answers the first question immediately, and the second question (was the bound wrong, or the execution?) becomes an engineering conversation instead of an incident with no owner.
Keep it fast
The list reads restrictive and operates liberating, which is the same argument as the approval map: explicit boundaries are what let automation run hard. Everything outside the seven classes needs no gate. Inside them, bounded execution keeps routine volume at machine speed, and only the genuinely consequential instances reach a person. If your agents feel slow under this model, the bounds are set wrong, and the fix is moving a threshold a named owner adjusts, never abandoning ownership.
I run my own operation this way because the boundaries predate the agents: editorial work is gated before anything publishes, deployments ship on an explicit go from the owner of the site, and lead capture notifies a person who decides the response. Permission boundaries have been my professional concern since long before LLMs; the security services architecture in my 2008 patent took on exactly this class of question, who may do what, granted by whom. The technology changed. The question did not.
Print the list. Put a name next to each line for every agent you run. The lines without names are your real risk register.
Questions worth asking next
What does a named owner mean for an AI agent action?
One person, identified by name, who owns the consequences of an action class and decides how it may run: per-instance approval, or pre-approved execution inside explicit bounds. The test is simple to run. Pick any consequential action your agent can take and ask who owns it. If the answer is a team name, a vendor, or silence, the action has no owner. Named ownership is what federal policy now requires for high-impact AI in agencies, where risk acceptance must carry a signature from the individual accepting the risk.
Can an AI agent ever act without human approval?
Constantly, and it should. Reversible work (drafts, analysis, staging changes) needs no gate at all. Six of the seven red-line classes allow pre-approved bounded execution: refunds under a threshold, emails from an approved template to an opted-in list, deployments through a gated pipeline an owner configured. Legal representation is the exception; a person signs every time. Nobody needs to click on every action. The requirement is that a named person decided the bounds, the log shows it, an emergency stop exists, and the authority expires and gets re-decided.
Are OAuth scopes enough to control an AI agent?
No, and they were never designed to be. Integration scopes answer what an agent can technically reach: this inbox, this repository, this payment API. Business consequence answers what an action can break: a customer relationship, a ledger, a production system, a legal position. An agent can stay perfectly inside its scopes while sending an email that ends a contract. Keep the scopes tight, then govern the seven consequence classes on top of them with named owners and explicit bounds.
Sources
- OWASP GenAI Security Project, "LLM Top 10 (2025)". https://genai.owasp.org/llm-top-10/
- OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications," December 9, 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
- OMB, Memorandum M-25-21, April 3, 2025. https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf
- Regulation (EU) 2024/1689 (EU AI Act), Article 14; text via the AI Act Explorer. https://artificialintelligenceact.eu/article/14/
About the practice behind this guide
I am Bob Michaels, a Web and AI Systems Architect in Austin, Texas. I have built the web since 1994, and today I run AI visibility measurement, complete web presence transformations, and custom AI system builds for organizations that want one accountable owner across all three. If your agents' permissions grew by integration instead of by decision, the review starts with this list and your org chart.
Evaluating me for an AI leadership role instead? The work record is here.