The 2026 AI Agent Security Report: What Agents Should Be Allowed to Read, Write, Send, Spend, and Delete

The bottleneck isn't capability, it's permission

AI agents can do real work right now. They can read your files, answer your email, update your records, and run tasks end to end. The thing holding most teams back is not the agent's skill. It is the lack of a clear rule for what the agent is allowed to do on its own. That is a permission problem, not a capability problem. Solve the permission problem and the capability is already there, waiting to be used.

Most thinking about "AI safety" falls into one of two traps. The first is confirm-everything: the agent stops and asks before every single action. The second is trust-nothing: you never let the agent act at all. Both traps kill the value. An agent that pauses on every step is just a slow, costly chatbot. An agent you never trust is a demo. Neither one does the job you hired it for.

The fix starts with a better definition of risk. Risk is not "doing things." Reading a file is doing something, and it is almost always harmless. Real risk is narrower than that. It is doing things that reach outside the sandbox, cost money, or cannot be undone. Once you name risk that way, the safe majority of an agent's work stands apart from the small slice that needs a human. You can say "yes, go ahead" to the large part and "check with me first" to the rest.

This report gives you a way to draw that line. It rests on five verbs, arranged as a ladder from lowest risk to highest: READ, WRITE, SEND, SPEND, and DELETE. Each rung increases one or more of three risk dimensions, blast radius, external exposure, and difficulty of reversal, so the permission you grant tracks the risk you actually take on. READ observes and analyzes. WRITE creates or changes information inside a system. SEND communicates outward. SPEND commits money or resources. DELETE destroys or makes things permanent. Each verb gets a memorable rule and a sensible default, so the whole model stays easy to hold in your head.

This is meant to be a Report you can cite. The framework is least privilege made practical, and it lines up with what the standards bodies and the model vendors already recommend. NIST's AI Risk Management Framework builds its whole approach around governance and human oversight of AI systems, as laid out in NIST AI 100-1. OWASP's list of top risks for LLM applications flags "excessive agency" as a core failure mode, covered in the OWASP Top 10 for LLM Applications. The five-verb line puts that guidance to work.

One disclosure before we start: Praxivara builds agent software, and it shows up once near the end as a reference implementation of this framework. The model stands on its own and on the cited standards, and you can apply it with any agent platform you choose.

READ: observe, retrieve, analyze, and run free

READ is the first and lowest rung. It covers everything an agent does to gather and reason over data the person already has access to. That means searching files, querying a database, reading email, calendar, or CRM records, pulling an API response, browsing the web, summarizing, analyzing, and drafting. A draft belongs here too. Drafting changes nothing until it is sent, so writing a reply or a report is still a READ output.

The risk on this rung is low, and it is low for concrete reasons. A properly scoped READ is non-mutating: it observes information without changing the underlying system. Its primary risks are unauthorized access, excessive collection, and disclosure, rather than a change to any system's state. The blast radius stays inside information the person already holds, and an agent that reads all day leaves every system exactly as it found it.

Two narrow risks are worth naming honestly. The first is exfiltration, where sensitive data gets read into a context where it does not belong. The second is over-reading, where an agent reaches for more than the task needs. Both are scope problems, not permission-per-action problems. You solve them by deciding up front what the agent can reach, not by pausing to approve each individual look.

The sensible default for READ is fully autonomous. Let the agent observe, retrieve, and analyze without a confirmation on every step. Gating reads turns a fast worker into a slow one and buys you almost no safety, because a scoped read changes nothing. What sensitive data the agent can reach is a scope decision, not a per-look approval.

There is one carve-out. A higher-sensitivity tier exists for things like raw credentials, other people's personal data, and regulated records. Access to that tier is a separate, narrower permission you grant on purpose. It is a scope decision, not a reason to gate ordinary reads.

That guardrail is least privilege, the oldest rule in security. NIST's control catalog names it directly in its SP 800-53 access-control family (AC-6), and the major cloud providers say the same. Amazon's guidance is to grant only the permissions required to perform a task. Set the scope well, and the whole rung can run free inside it.

WRITE: create and change, kept reversible

WRITE is the second rung. It covers creating or changing information inside a system the person already controls: updating a CRM record, editing a spreadsheet or a shared document, rescheduling an appointment, creating a task, moving a deal to a new stage, marking an invoice paid, changing a status, or modifying a configuration. Unlike READ, a WRITE changes state. Unlike SEND, it stays inside a system you own instead of going out to another party.

The risk here is real but usually contained. A write alters data, so it is not non-mutating the way a read is. But most writes happen in a system that keeps history, which means the change can be reviewed and rolled back. The question that sets the risk is not whether something changed. It is how far the change reaches, and how easily it reverses.

The sensible default for WRITE turns on reversibility and scope. Reversible changes inside a pre-approved system may proceed and be logged. Changes that affect permissions, identity, account settings, contractual records, or shared configuration should wait for approval. Turn on version history wherever the system allows it.

That split does most of the work. Editing a draft, updating a contact, or creating a task is routine, recoverable, and fine to run on its own with a log entry. Granting someone access, changing a billing plan, rewriting a legal record, or altering a shared configuration reaches further and is harder to walk back, so it earns a human check. The line inside WRITE runs along the same axis as the whole ladder: how far the change reaches, and how easily it comes back.

This is why version history matters so much for agents. A system that versions every edit turns WRITE into a reversible verb, and a reversible verb is a safe one to hand off. Let the recoverable writes flow, and put the identity-and-permission writes in front of a person.

SEND: communicate outward, then trust

SEND is the third rung. It covers any action that pushes information out of the sandbox to another party. That includes sending an email, posting a message or DM, replying, submitting a form, publishing a page, creating a calendar invite, firing a webhook, opening a ticket, or calling an outside API that changes someone else's system. The moment a bit leaves the person's private context, you are on this rung.

The risk rises here, and it rises for a specific reason. SEND crosses from a private workspace into the outside world. Two things change at that line. First, perception becomes hard to reverse. You can delete a sent email, but you cannot un-send the fact that someone already read it. The bits are recoverable. The social and legal effect is not. Second, the message goes out under the person's name, so their reputation and relationships are now exposed.

Not every send carries the same weight. A routine note to a teammate inside the same workspace is low-stakes. A first-time email to an outside client, a public post, or anything that speaks for the person to a third party is high-stakes. The permission should track that difference.

The sensible default for SEND is graduated: notify and proceed for routine internal communication, and require explicit approval for first-time recipients, public posts, or anything going out under the person's name to a third party. Low-stakes sends keep the agent moving. High-stakes sends pause for a quick look. You get speed where it is safe and a check where it matters.

The model vendors already build to this shape. OpenAI's agent guidance treats approvals as the human step before a side effect, where the run pauses until you approve or reject the call. Anthropic's framework for safe and trustworthy agents holds that people should keep control before high-stakes decisions. Both point to the same line. Let the routine message go, and put the outward-facing one in front of a human first.

SPEND: commit money or resources, approve by default

SPEND is the fourth rung, and here the risk takes a real jump. SPEND is any action that commits money or a scarce resource. That covers far more than card charges. It includes buying goods or services, sending payments or transfers, provisioning paid infrastructure, burning through a rate-limited API budget, or allocating credits. If the action draws down something finite, it is a SPEND.

The reason SPEND sits above SEND is simple. A spend is externally binding, and it is often hard to claw back. A placed order, a sent payment, or a signed commitment creates an obligation in someone else's system. That obligation does not reverse just because you ask. The blast radius is now financial and contractual, not just informational.

So the sensible default is plain. Approval is required for anything that moves money. The one autonomous lane is a narrow, pre-authorized budget envelope: a standing cap for a known vendor, under a set ceiling. Inside that envelope, the agent can act. Outside it, the agent stops and asks.

Here is the part people miss. Approval-by-default on SPEND is not a handcuff. It is the trade that sets the rest of the ladder free. A confirmation card on a payment costs a few seconds and saves real money. Because you hold the line firmly at the top, you can let READ and routine SEND run without a second thought. The strict gate up high is exactly what earns the freedom lower down.

One design rule makes this hold. Money actions should be stopped at the platform, not left to the model's judgment. The model can be confused, misled, or simply wrong. A hard platform gate does not care. This is the direct fix for the excessive agency risk that OWASP flags, where the root cause is often too many permissions handed to the agent in the first place.

DELETE: destroy or make irreversible, stop and ask

DELETE is the top rung, and it is the irreversibility verb. DELETE means permanently removing data: emptying the trash, hard-deleting files, emails, or records. It also covers any action you cannot undo. Overwriting something with no history, revoking access other people depend on, tearing down infrastructure, or closing an account all belong here.

DELETE is the highest risk because it raises all three dimensions at once. The blast radius is at its widest. The reversibility is zero. And the effect often reaches outside your own walls. There is no notify-and-proceed option here. By the time you notice the mistake, the thing is already gone.

So the default is firm. Approval is required for any destructive action. And for anything truly irreversible, go one step further. Prefer soft-delete, tombstone, or versioned patterns, so the agent's version of delete is itself reversible. The real hard-delete stays a human action, made on purpose.

This is where the pro-agent case is strongest. Making deletes reversible by design is what lets an agent work in this territory at all. A soft-delete you can restore turns a frightening verb into a safe one. The agent gets to act, you get to take it back, and nobody loses sleep over a bad call. Reversibility is not a brake on autonomy. It is the thing that makes autonomy here possible.

Build delete this way and the top of the ladder stops being scary. You are not slowing the agent down. You are drawing one clean line, so the safe majority of actions never has to pause.

This lines up with the major guidance. NIST's AI Risk Management Framework puts human oversight at the center of trustworthy AI. For U.S. federal agencies, OMB Memorandum M-25-21 requires human oversight and intervention for high-impact AI uses. It governs federal use rather than private software, but its risk-based oversight principle points the same way, and a permanent delete is about as high-impact as it gets.

The approval line: where autonomy stops and sign-off begins

The ladder gives you five rungs. The approval line is the single cut across them. On one side, actions run on their own. On the other, they wait for a person. READ, reversible WRITE, and low-stakes SEND sit on the autonomous side. Sensitive WRITE, high-stakes SEND, every SPEND, and every DELETE sit on the sign-off side.

The line does not track how much work the agent does. It tracks three things: whether an action reaches outside the sandbox, whether it costs money, and whether it can be undone. A task that touches a thousand files but changes nothing stays autonomous. A single click that sends money or erases a record does not. Effort is not risk. Reach, cost, and reversibility are.

A good approval is not a wall. It is a card. The action shows up as something a person can read in seconds, then approve, edit before it goes, or decline. The run pauses. It does not die. When you approve, the agent picks up where it left off. The card carries enough context to decide fast, so the sign-off costs seconds and not minutes.

This is exactly how the model vendors build it. OpenAI's agent guidance treats approvals as the human-in-the-loop path for tool calls, where the run pauses until you approve or reject and the agent stops before side effects. Anthropic's framework for safe and trustworthy agents says humans should keep control before high-stakes decisions, and Claude Code runs read-only by default and asks before it changes systems.

The standards bodies say the same. OWASP names Excessive Agency as a top risk for LLM apps and recommends human-in-the-loop control to approve high-impact actions. The U.S. federal AI memo, OMB M-25-21, requires adequate human oversight and the ability to step in on high-impact AI. And NIST's AI Risk Management Framework puts governance and human oversight at the center of trustworthy AI.

That agreement is the point. NIST, OMB, OWASP, and both leading model vendors all point the same direction: least privilege, human control over consequential actions, auditability, and reversible defaults. The five-verb framework is our synthesis of those principles. Its exact categories are our own; the principles underneath it are the industry's. For a plainer walkthrough of what to hand off first, see our guide to the approval line for small business agents.

When an action is more than one verb: the strictest wins

Real agent actions do not always sit in one lane. Many carry two verbs at once. Reading data through a paid API is a READ and a SPEND. Sending a paid ad campaign is a SEND and a SPEND. Emailing a file and then removing it is a SEND and a DELETE. Changing a billing plan is a WRITE and a SPEND. Revoking another person's access is a WRITE and, in effect, a DELETE.

This keeps the lanes from pretending to be mutually exclusive when the real world overlaps them. Classify an action by its riskiest part, not its friendliest one, and the approval line still falls in the right place.

Least privilege: scope the credential, not the click

The approval line handles the moment of action. Scoping handles everything before it. The idea is old and simple. Give any worker the least access the job needs, and nothing more. Security people call it least privilege. It is the other half of a safe agent.

NIST writes least privilege into its control catalog, SP 800-53, as control AC-6: grant users only the access their assigned tasks require. The cloud vendors say it in plainer words. AWS tells teams in its IAM best practices to grant only the permissions required to perform a task. Google Cloud tells teams to grant roles at the smallest scope needed, and to treat each part of a system as its own trust boundary with its own identity.

The joint UK NCSC and U.S. CISA Guidelines for Secure AI System Development apply the same rules to AI itself: use least privilege, pick safe defaults, and sandbox untrusted components.

For an agent, this means each tool is connected once and scoped to exactly what the task needs. Permissions are granted per tool, not in one broad handful. An agent that works in your calendar has no reach into your bank. An agent that reads one inbox cannot touch a system it was never given. The scope is set up front, so you are not asked to approve every single read.

This is also what dissolves the two small risks of reading we named earlier: pulling sensitive data into a place it does not belong, and over-reading past the task. Both are scope problems. You fix them by scoping the credential, not by stopping to confirm each look. Tighten what the agent can reach, and the reads inside that boundary can run free.

OWASP frames the same fix from the risk side. Its Excessive Agency entry traces the danger to three roots: too much functionality, too many permissions, and too much autonomy. The fixes mirror this model. Cut the tools to what is needed, enforce least privilege, and keep a human on high-impact actions.

Audit and reversibility: the safety net under the ladder

The five-verb ladder tells an agent when to act and when to wait. Two more properties sit underneath the whole thing and make it recoverable: audit and reversibility. They are what turn "what if the agent gets it wrong" from a reason to say no into a managed, bounded risk.

Start with audit. Every action an agent takes should be logged and timestamped into a complete, openable history. Nothing off the books. That record is not just for compliance. It is the reason you can safely grant more autonomy, not less. A fully logged agent is one you can review after the fact, correct when it drifts, and hold accountable for what it did. An agent whose actions vanish is one you have to supervise in real time, which defeats the point of handing off the work. Complete logging is the classic control here. NIST's SP 800-53 catalog carries a whole audit and accountability family for exactly this reason, and its AI Risk Management Framework puts accountability at the center of its GOVERN function.

Reversibility is the second net. Design actions so they are reviewable and undoable by default, so a mistake is a shrug rather than a disaster. In practice that means a few plain patterns. Soft-delete instead of hard-delete, so a removed record can be restored. Drafts instead of auto-send, so a message can be checked before it goes out. Versioned edits instead of overwrites, so the prior state is always there. And an instant pause or stop on a running agent, so a human can step in mid-task without waiting for the run to finish.

Put these together and the throughline is simple. When most actions can be undone and all actions are on the record, a wrong step is a step you can walk back, not a hole you fall into. That is what makes autonomy defensible to a cautious buyer. The guardrails do not rest on the model always using good judgment. They are properties of the platform itself, true whether the model is sharp that day or not. You review the log, you undo the miss, and the agent keeps earning trust instead of spending it. This is the foundation the whole permission model stands on.

The payoff: a permission matrix you can actually run

Here is where the whole model becomes something you can run, not just read. Map each verb to a default autonomy level and the five-verb ladder turns into a single grid. Every action an agent might take lands in a defined lane, so the agent is never guessing and you are never surprised.

The lanes are four. Auto means proceed. Notify means proceed, record it, and tell you after. Approve means pause and wait for your sign-off card. Block means the action does not run as written and gets forced into a reversible path instead. Read the grid across each verb and the defaults fall out cleanly.

Walk it once. READ runs on Auto, with a narrow Approve carve-out for a higher-sensitivity tier like raw credentials or other people's records. WRITE runs on Notify when the change is reversible and inside a pre-approved system, and moves up to Approve when it touches permissions, identity, or shared configuration. Low-stakes internal SEND runs on Notify. Public or third-party SEND moves up to Approve. SPEND sits on Approve by default, with a pre-authorized budget envelope as the only lane that runs on its own. DELETE waits for Approve. And a hard, irreversible delete gets Blocked, meaning it is not allowed to run as a true destruction and is pushed into a soft-delete or versioned pattern instead.

Use this as a starting policy, not a fixed law. Tune it per role and per tool. A support agent and a finance agent should not carry the same defaults, and a read-only reporting tool can sit lower than one that can post. The point of the grid is that every lane is decided in advance, up front, rather than argued out on each action.

This is the payoff the whole report has been building toward. You get the full share of autonomous value from the safe majority of actions, and you keep the risky few on a short leash. Capability and control at the same time. That is agents done right, and the matrix is how you actually ship it.

A reference implementation: how Praxivara enforces the line

A framework is only as good as a system that actually runs it. Praxivara builds agent software, and its guardrails are a working example of the five-verb line put into practice. What follows is a worked example, not a pitch. The point is to show that every principle in this report maps onto real, shipped behavior, and that the guardrails live in the platform rather than in the model's good intentions.

Seven guarantees carry the load, and each one lines up with a section above.

• Your sign-off gates anything sensitive. Routine work runs on its own. The moment an action leaves your walls or touches something that matters, it stops and waits for you. That is the approval line, drawn exactly where risk lives.
• Money and admin actions are stopped at the platform. The wall does not depend on the model reading the situation correctly. Even if the agent is fed a bad instruction, it cannot move money or change account settings without a human. This is the SPEND rung enforced in code, not judgment.
• Least privilege, one secure connection at a time. Each tool is connected once and scoped to what the task needs. An agent working in one system has no reach into another it was never handed.
• Every action is logged and timestamped. Nothing runs off the books. The full history is there to open, review, and correct after the fact.
• Approvals arrive as a card. When something needs you, it shows up as a clear card you can approve, edit before it goes, or decline. The run pauses in place instead of dying.
• Agent code runs sealed off. When an agent executes code, it runs with no network access, so the sandboxed code cannot open an outbound connection of its own. That removes one major exfiltration path. Integration permissions, model context, logs, and any approved outbound action still have their own separate controls.
• Reversible by default. Actions favor drafts, soft-deletes, and versioned edits, with a confirmation before anything that cannot be undone, plus an instant pause and stop on any running agent.

These behaviors are confirmed live across the assistant and the agents product, not roadmap promises. Read one more time and the pattern is plain. Sign-off gates the risky verbs. Money and admin are walled at the platform. Scope is tight, logs are complete, and the default is something you can take back.

That is the whole argument of this report expressed as a product. The guardrails are properties of the platform, not memories the model has to hold onto. That is exactly what the standards ask for, and it is what lets a person hand an agent real work without holding their breath.

FAQ: the questions buyers actually ask

Are AI agents safe to let act on their own?

Yes, when the permission you grant tracks the risk you actually take on. Safe autonomy is a permission-model question, not a capability question. An agent that reads and drafts freely, while pausing on money and irreversible actions, gives you the upside with a bounded, recoverable downside.

What permissions should an AI agent have?

Exactly what the task needs, and nothing more. Scope each tool one at a time so an agent in one system has no reach into another. Then let the five-verb line set the defaults: READ runs free, WRITE proceeds and logs when reversible, SEND graduates from notify to approve, and SPEND and DELETE wait for a person.

How does human-in-the-loop approval work without slowing everything down?

It only fires at the approval line: high-stakes sends, anything that spends, and anything that deletes. Routine reads and low-stakes internal messages never pause. So the agent moves at full speed on the safe majority of work, and you only see a card for the handful of actions that genuinely warrant a second look.

What are the main AI agent risks for a small business?

Three, and all three have clean fixes. Over-broad permissions are solved by scoping the credential per tool. Unreviewable actions are solved by logging everything into an openable history. Irreversible mistakes are solved by reversible-by-default patterns like soft-delete and drafts. Address those and the scary version of the risk goes away.

What standards back this up?

The same guidance the major players already publish. NIST's AI Risk Management Framework puts governance and human oversight at the core, and its SP 800-53 catalog defines least privilege and audit logging. OWASP's Top 10 for LLM Applications names excessive agency as a top risk and recommends human sign-off for high-impact actions. Both Anthropic and OpenAI ship the same pattern in their own agent tools. When you decide what to hand off first, the small business automation report is a good place to start.

Methodology and sources

This report is a synthesis, not a survey. It draws its principles from published guidance and puts them into one practical model. The sources: NIST's AI Risk Management Framework and its SP 800-53 control catalog, OWASP's Top 10 for LLM Applications and its Agentic security guidance, the OpenAI and Anthropic agent frameworks, OMB Memorandum M-25-21, the joint UK NCSC and U.S. CISA guidelines for secure AI system development, and the current AWS and Google Cloud least-privilege guidance. All were reviewed in August 2026. The READ, WRITE, SEND, SPEND, and DELETE ladder is Praxivara's original synthesis of those principles, and the exact categories are our own.

Conclusion: give agents the keys, keep the ledger

The reason to hesitate on agents was never that they cannot do the work. They can, and they do it well today. What was missing was a clean way to say which work is safe to hand off outright and which work needs a human in the room. The five-verb ladder is that way, and it is simple enough to remember.

READ runs free, because reading changes nothing and the guardrail is scope. WRITE creates and changes inside your own systems, running on its own when the change is reversible and pausing when it touches identity or permissions. SEND graduates from a quiet notice to a real approval as the message goes more public and more permanent. SPEND waits for a person whenever it settles in someone else's ledger. DELETE never happens without your sign-off, or without a reversible pattern sitting underneath it so the agent's version of delete is one you can take back.

Wrap that ladder in its two safety nets, least-privilege scoping up front and audit plus reversibility behind, and you get autonomy that is bounded, recoverable, and legible. You can see what the agent did, you can undo it, and you were never surprised by it.

Here is the founder's note to end on. This is not caution as the price of capability. Done right, the permission model is the thing that unlocks capability, because a person who can trust the line will grant far more freedom than a person who cannot. The clearer the line, the longer the leash. Give the agent the keys, and keep the ledger.