Agents fail differently from chatbots
A chatbot can be wrong. An agent can be wrong and then do something. That difference is why professional teams need an authority model before agent workflows become normal business infrastructure.
The current AI discussion reflects that shift. A last30days run surfaced r/AI_Agents threads asking who gave an agent authority and how teams should run multi-step LLM workflows in production. Government adoption is moving at the same time: California announced discounted Claude access for state and local government use, and federal policy is increasingly focused on frontier AI safety and security review.
Authority is not one permission. It is a ladder. Reading a policy document is different from drafting a response. Drafting a response is different from sending it. Sending a message is different from approving a refund, rejecting a candidate, deleting a record, changing a payroll entry, or deploying code. A useful governance policy names each level instead of saying "the agent has access."
The core question is not whether the agent is smart enough. It is whether the organization has authorized the exact action the agent is about to take.
The authority matrix
Start with a permission matrix that separates data access from action authority. Many teams accidentally skip this distinction because their automation platform grants broad tool access. An agent that can read a CRM record should not automatically be allowed to update it. An agent that can draft a customer email should not automatically send it.
| Authority level |
Example |
Default rule |
| Read |
Search approved docs, tickets, CRM notes, policies. |
Allowed only for scoped data categories. |
| Draft |
Prepare an email, report, ticket update, job description, or code diff. |
Allowed with human review before external use. |
| Recommend |
Suggest next steps, triage category, risk level, or routing. |
Allowed when recommendation criteria are documented. |
| Update |
Change a CRM field, ticket status, inventory record, or internal note. |
Requires approval for sensitive or customer-impacting changes. |
| Send or transact |
Send messages, issue refunds, place orders, approve expenses. |
Human approval by default; narrow exceptions only. |
| Irreversible action |
Delete records, terminate access, reject candidates, deploy production changes. |
Restricted; require explicit owner, audit log, and rollback plan. |
Three workflow examples
Customer support agent
The agent may read product documentation, customer tickets, and approved macros. It may draft a reply and recommend a triage label. It should not send the reply, issue a refund, promise roadmap dates, or disclose account-sensitive information without approval.
HR policy agent
The agent may draft policy summaries and answer FAQs from approved policy text. It should not make employment decisions, infer sensitive employee traits, update personnel records, or send manager guidance without HR review.
Engineering agent
The agent may inspect a repository, edit scoped files, run tests, and draft a pull request. It should stop before changing auth, billing, data deletion, deployment, or security configuration unless a named human approves the step.
Agent authority record:
agent_name: support-triage-agent
purpose: draft customer-support replies and triage labels
data_allowed:
- product docs
- current ticket
- approved support macros
data_forbidden:
- payment details
- private account security notes
actions_allowed:
- draft reply
- suggest label
- suggest escalation
requires_approval:
- send reply
- promise refund
- disclose account-specific diagnosis
logs:
- source records read
- draft output
- approver
- final action
Governance checklist
Name the ownerEvery agent needs a business owner and technical owner.
Separate permissionsRead, draft, recommend, update, send, approve, delete, and spend are different powers.
Log the pathRecord data read, tools called, output drafted, approver, and final action.
Define revocationKnow how to disable the agent, rotate credentials, and review recent actions.
FAQ
Can low-risk agents act without approval?
Yes, but only after the action is narrow, reversible, logged, and bounded by clear policy. Internal formatting or label suggestions are different from external customer messages or financial actions.
Who should own agent authority?
The business function should own the decision, security should own access controls, legal/compliance should review high-risk workflows, and engineering should own implementation and logs.
What is the first policy to write?
Write a simple authority matrix before a long AI policy. Teams need to know what the agent may read and do before arguing about model choice.