What Agents Are Allowed To Do

Software permissions used to be an administrative matter. Someone tracked which person could reach which system, which application could call which interface, and which manager signed off on a change. Agentic AI makes the same question strategic, because an agent can reason across context, call tools, trigger workflows and act before any manager has reviewed what it did. Give it too little access and it never gets past the demo; give it broad access and the company has an operator using borrowed authority that nobody directly oversees.

Prompts do little to limit what an agent can do. The permission list sets its authority, so the list is the control to get right.

An agent's authority should stay inside the business decision it is allowed to improve.

The National Institute of Standards and Technology (NIST) summary of 2026 responses on AI agent security treats agent adoption as a security and trust problem. Respondents agreed that AI agents bring new threats and that existing cybersecurity practices must adapt. McKinsey's 2026 analysis of agentic infrastructure comes to the same view from the technology side: systems ready for agents need clear digital identity, ownership, logging, auditability, policy enforcement, and supervisory mechanisms that can pause or override automated behavior. For executives, the harder failure is an allowed action carried out at the wrong time, for the wrong reason, with the wrong data or at the wrong scale.

Separating the account from the agent that uses it

Human access control assumes a person sits behind each account, so a reviewer can ask who clicked, who approved, who knew the customer and who should have escalated. Agents blur that trail. A sales agent may reuse a salesperson's Customer Relationship Management access, and a finance agent may inherit someone's spreadsheet permissions. Support agents pull account status and prepare refund language; coding agents read repositories, open pull requests and call third-party tools. The access in each case was granted to systems and people, but the agent is the one using it.

A company that cannot tell the account from the actor has no answer to the first question an auditor will ask: was this a human decision, an AI recommendation, an AI execution, or a machine step approved by a named human?

Six permissions

A practical permission list starts with six lines, written plainly enough to get through review by procurement, legal and security as well as engineering.

Each line sets how much trust the business extends to the system, and it deserves the scrutiny a company would give a capital allocation.

What OWASP's agent risk list tells executives

The Open Web Application Security Project (OWASP) work on agentic AI security gives names to risks that operators may sense but cannot yet govern. Its guidance covers prompt injection, tool abuse, privilege escalation, data exfiltration, memory poisoning, goal hijacking, excessive autonomy, high-impact action abuse, approval manipulation, cascading failures, wallet denial, sensitive-data exposure, and supply-chain compromise. The list is long because an agent folds application, identity, data, operating and cost risk into a single delegated workflow.

The permission table should therefore sit above any single team. Security defines controls and engineering implements scopes and logs; legal decides which external commitments are unacceptable, finance sets cost thresholds, and the business owner defines the task and when to escalate. None of them can set the full scope alone, since it has to reflect all of those risks at once.

Four controls before production

Before any agent moves from pilot to production, the permission list should require four controls.

1. A named human owner

Every agent needs an owner who answers for the business outcome and the harm model. "The AI team" is not an owner. The owner must know what the agent may optimize, what it must never do, and when it has to stop.

2. Scoped credentials

An agent should not inherit broad human authority by default. Give it the narrowest permission set that still does the job: read-only where possible, write-limited where needed, approval-gated for sensitive steps, time-bound for risky experiments, and kept apart from personal user accounts.

3. Audit-grade logs

The logs must let someone reconstruct what data the agent saw, what it inferred, which tools it called, which records it changed, which human approved any high-impact step, and what happened as a result. A system whose logs cannot explain the workflow should not be trusted in production.

4. A kill right

Someone must be able to pause, disable, roll back or downscope an agent when costs spike, data is exposed, behavior drifts, policy conflicts or an error reaches a customer. If invoking the stop rule needs a committee meeting, the damage will be done before the meeting is convened.

What buyers should ask vendors

Enterprise buyers should ask vendors for the permission list before they ask for another demo. A demo shows what the agent can do on a clear path, whereas the table tells the company whether it can live with what the agent is allowed to do when conditions turn. Buyers need to know whether tool use can be restricted by role, data class, workflow, geography, customer segment or action type. They should be able to see which agent touched which system and to require human approval for high-impact steps. Drafting, recommendation, execution and learning should stay separable, and revoking one permission should not break unrelated work.

These questions look slower than a run of demos. In practice they speed adoption, because they let the buyer approve narrow autonomy where it would otherwise have to reject an opaque system outright.

A version for founders

Small companies need this more, because their informal permissions are usually thinner. A founder may have access to everything, and the first agent may run from the founder's laptop, email account, application programming interface (API) key or admin console. That feels efficient until the agent updates a Customer Relationship Management record, makes a support promise or exposes a private memo.

The founder's version of the table fits on one page:

1. Which business decision does this agent improve?
2. What is the narrowest data set the task requires?
3. Which actions are allowed without approval?
4. Which actions require explicit approval?
5. What cost ceiling stops the workflow?
6. Which customer, legal, security or finance events force escalation?
7. Who can revoke the agent's access today?

If those answers are missing, keep the agent in assist mode, where it drafts, classifies, searches, summarizes or prepares options. Hold back execution across systems until the permission scope is real.

What each unit of autonomy costs

Permission scoping works best as a control backed by accounting. A well-scoped agent can cut response time, remove friction at handoffs and free expert teams for judgment work. Every unit of autonomy it gets still draws on data access, inference budget, tool authority, human review capacity and institutional trust, and the permission list is the document in which the company weighs those costs against the return.

Seven questions before expanding access

Before an agent's access grows, require seven answers.

1. Who owns the agent's business outcome and harm model?
2. Which read, reason, write, spend, message and change permissions does it have?
3. Which permissions are temporary, scoped, approval-gated or prohibited?
4. What audit trail shows what the agent saw, inferred, called, changed and escalated?
5. Which cost, error, data, customer or security event triggers a stop?
6. Who can revoke access immediately?
7. Which business decision improves enough to justify the remaining risk?

If the seventh answer is weak, keep the other six and use them to force a smaller pilot. The companies that move fastest will know where permission creates value, where it creates liability and where the machine must hand authority back to a person; blanket access, in practice, slows a company down. Agentic AI will arrive through support queues, sales workflows, coding tools, finance analysis, security operations and personal productivity habits.