Agents become risky when they are given tasks before they are given boundaries. If an AI system can plan, browse, use tools, work with files, or operate inside a workflow, the real operator question is not \u201cCan it do the job?\u201d It is \u201cWhat is it allowed to touch, change, and finish without approval?\u201d<\/p>\n
Recent agentic model releases are being positioned around more action-oriented work. Anthropic\u2019s Claude Sonnet 5 announcement<\/a>, for example, describes a model built to make plans and use tools such as browsers and terminals. That matters because the workflow is no longer limited to producing text for a human to copy.<\/p>\n A chat answer can be wrong and still remain contained. An agent with tool access can inspect a page, draft a file, prepare a code change, update a workspace, submit a form, or trigger the next step in a process. The business risk moves from bad output to bad action.<\/p>\n Most teams do not have an agent problem. They have a workflow authority problem. They ask, \u201cWhat can we automate?\u201d before asking, \u201cWhich parts of this workflow should never be automated without a named owner?\u201d<\/p>\n That is the shift this article fixes. Treat agents like junior staff with permission levels, not magic software with unlimited access.<\/p>\n Before assigning an agent a task, define the operating agreement. This is not only a technical setting. It is a business rule: what the agent may read, what it may produce, what it may change, and where it must stop.<\/p>\n Start with five inputs. First, name the workflow narrowly. \u201cSales operations\u201d is too broad. \u201cPrepare renewal account notes from approved CRM fields\u201d is usable. Second, name the human owner. The agent can perform work, but a person owns the consequence.<\/p>\n Third, list the systems involved: browser, inbox, CRM, spreadsheet, code repository, analytics dashboard, internal documents, ticketing tool, payment system, or automation platform. Fourth, classify the data. Customer names, private emails, invoices, contracts, credentials, legal material, financial details, and internal strategy notes deserve tighter controls. Do not upload confidential or sensitive data by default. Use the least data needed, check company policy, and keep access tied to the workflow.<\/p>\n Fifth, define the action boundary. Reading a policy document is not the same as editing it. Drafting a customer reply is not the same as sending it. Recommending a refund is not the same as issuing one. The boundary is where convenience becomes exposure.<\/p>\n For more systems thinking around this kind of workflow design, keep Business Systems & Operations<\/a> close to the implementation conversation.<\/p>\n Use this matrix whenever an agent touches tools, files, customer records, code, browser sessions, internal documents, or automation platforms. Assign permission by system, not by agent. The same agent may be read-only in one system, draft-only in another, and approval-gated in a third.<\/p>\n The agent can inspect approved inputs and return summaries, comparisons, extractions, or analysis. It cannot change anything.<\/p>\n The agent can prepare text, records, code, tasks, or messages for human review. It cannot publish, send, merge, deploy, or save into a live system.<\/p>\n The agent can analyze options and propose a decision. A human still decides.<\/p>\n The agent can perform low-risk actions that are logged and easy to undo.<\/p>\n The agent must stop before irreversible or high-risk action. This is the line that protects the business.<\/p>\n The most important line is between reversible and irreversible work. \u201cHuman in the loop\u201d is weak if the human only appears after the damage is done. A useful approval gate sits before the agent crosses a business boundary.<\/p>\n Once the matrix is written, turn it into operating practice. The point is not to create paperwork. The point is to make the agent\u2019s authority visible before the first run.<\/p>\n Imagine a marketing operator preparing a launch email. A poor instruction says: \u201cResearch the product, write the email, update the campaign, and send it.\u201d A better instruction says: \u201cRead the approved product brief, draft three email options, recommend one for the stated audience, prepare a draft campaign entry if drafts are available, and stop before scheduling or sending.\u201d The difference is not a better model. It is better permission design.<\/p>\n The same logic applies to coding. An agent may inspect a bug report, draft a failing test, propose a fix, and explain its changes. Merging, deploying, deleting data, touching credentials, or changing production behavior should require human approval unless the business has a mature release process with separate safeguards. The agent may do the mechanical work. The operator owns the consequence.<\/p>\n The first failure mode is permission stacking. A team gives read access to documents, write access to a workspace, and browser access for research, then treats the combination as harmless. It is not. Read plus write plus web action creates operational reach.<\/p>\n The fix is to review the workflow as a chain. Ask: if the agent reads this input, drafts this output, and can click this button, what could happen without another person noticing? If the answer includes customer impact, money movement, legal commitment, production change, or public communication, add an approval gate.<\/p>\n The second failure mode is hiding judgment inside administrative language. \u201cUpdate account tiers,\u201d \u201capprove this refund,\u201d \u201cprioritize these leads,\u201d and \u201cclean this database\u201d can sound simple. They often contain policy interpretation, customer context, exceptions, and commercial judgment. Let the agent recommend unless the rule is explicit and the action is low-risk.<\/p>\n The third failure mode is trusting self-checks too much. An agent may review its own output or continue until it believes the job is complete. That can catch obvious gaps, but it does not replace business review. The model checks against its instruction. The operator checks against policy, customer context, permissions, brand risk, and commercial impact.<\/p>\n The fourth failure mode is expanding data access because it is convenient. Convenience is a weak reason to expose private data. Redact what the agent does not need. Use sample records for testing. Prefer approved knowledge bases over inbox dumps. Keep private data out unless there is a clear policy, a clear owner, and a clear need.<\/p>\n Use this prompt before an agent begins work with tool access. Fill the fields yourself. Do not ask the model to invent its own authority.<\/p>\n This belongs at the start of the run, not after the agent has already wandered through the workflow. Attach it to the workflow documentation and make the owner update it when systems, rules, or risk levels change.<\/p>\n For more practical AI operating patterns, the AI in Practice<\/a> pillar is the right place to connect tool use with human review.<\/p>\n The obvious objection is that permission gates slow agents down. In the first version of a workflow, they do. That is acceptable. The goal is not maximum autonomy on day one. The goal is safe autonomy in the parts of the workflow where the business can tolerate machine action.<\/p>\n Removing approval too early creates expensive speed: wrong emails sent quickly, records changed without context, files overwritten, duplicate tasks created, or customer promises made by accident. The better question is not \u201cHow do we remove the human?\u201d It is \u201cWhich approvals still carry real judgment?\u201d<\/p>\n Some gates can loosen over time. If an agent reliably applies internal ticket labels under clear rules, that may become reversible execution. If it drafts renewal notes well but pricing depends on account history, keep pricing under human approval. Permission levels should move with evidence, not excitement.<\/p>\n This is also why tool selection should not start the conversation. The workflow decides the permission model. The tool only runs inside it. Use Tools & Teardowns<\/a> thinking after the boundaries are clear, not before.<\/p>\n Pick one agent workflow your team wants to automate. Before writing the task prompt, write its permission levels: owner, inputs, systems, data restrictions, allowed actions, approval triggers, and action log. If you cannot name those items, the workflow is not ready for autonomy.<\/p>\n Start with read-only or draft-only work, review the output, then promote permissions only where the action is reversible, logged, and boring. AI is the engine. The operator is the architect.<\/p>\n Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment<\/a>.<\/p>\nDefine authority first<\/h2>\n
The approval matrix<\/h2>\n
Level 1: Read-only<\/h3>\n
\n
Level 2: Draft-only<\/h3>\n
\n
Level 3: Recommend<\/h3>\n
\n
Level 4: Reversible action<\/h3>\n
\n
Level 5: Approval required<\/h3>\n
\n
Run the workflow<\/h2>\n
\n
Where agents fail<\/h2>\n
Permission prompt<\/h2>\n
You are acting as a workflow agent under explicit permission limits.\n\nBusiness context:\nWorkflow name:\nHuman owner:\nBusiness objective:\n\nAllowed inputs:\nApproved documents, records, pages, repositories, datasets, or tools:\nInputs that are not allowed:\n\nData restrictions:\nUse only the minimum data required for the task.\nDo not request or use confidential, regulated, credential, payment, legal, medical, or unnecessary personal data unless the human owner confirms approved access.\nIf required information is missing, ask for the minimum safe input.\n\nPermission levels by system:\nSystem 1:\nPermission level: read-only, draft-only, recommend, execute reversible actions, or request approval for irreversible actions\nSystem 2:\nPermission level:\nSystem 3:\nPermission level:\n\nApproval triggers:\nStop and request human approval before any action that sends, publishes, deletes, overwrites, purchases, changes billing, changes permissions, modifies customer records, commits code, deploys, submits a form, or creates an external obligation.\n\nTask:\n\nRequired output:\n1. Planned steps before action.\n2. Work performed within the permission limits.\n3. Drafts or recommendations produced.\n4. Items that require human approval.\n5. Assumptions, uncertainties, and missing information.\n6. Action log showing inputs used and changes made.\n\nQuality rule:\nIf the task requires authority beyond the listed permission levels, stop. Do not improvise around the limit.<\/code><\/pre>\nThe speed objection<\/h2>\n
Next step<\/h2>\n
\nWhere does your business actually stand?<\/h3>\n