Give an agent enough authority to be useful and you have given it enough to be dangerous. The same agent that drafts the reply could send it; the one that reads the records could delete them. The usual answers are both bad. Lock it down so it can only read, and it cannot do the work. Open it up so it can act, and a single bad call is irreversible.
The real answer is that not all actions are equal, and an agent should be trusted differently for each. So we sort actions by severity, and we give the agent a clean way to ask for more authority on the rare occasions it needs it.
Not all actions are equal
Permissioned actions sort into four severity levels. Low is reading accessible content and summarizing it, the things you would let an agent do all day without a second thought. Medium is editing non-critical content or drafting an outbound message, real work but reversible.
High is the irreversible or externally visible: sending something outside the company, changing who has access, deleting content. Critical is the rare and grave: transferring ownership, granting broad connector access, destructive bulk operations. The severity of an action, not just whether it is permitted, decides how much standing trust it gets.
Who sets the ceiling depends on the kind of agent. For an assistant, which acts as a private extension of one person, the severity limit is tied to that owner. For an independent agent with its own identity, the invoking user chooses the authorized severity for the scoped request they are making. Either way, a human decides how far the agent may go without checking back, and the agent cannot raise that line itself.
Two different questions
There are two questions hiding in every agent action, and keeping them separate is the whole design. The first: does the agent have a grant for this action at all? The second: did the user authorize the agent to use that level of authority without asking again?
A grant says the agent may attempt the action. The user's authorized severity says how far it may go on its own. You can give an agent a grant to manage a mailbox and still say: read and summarize freely, but check with me before you send anything outside. The grant and the severity ceiling are different dials, and an agent is most useful when they are set independently.
When it needs more, it files an intent
So what happens when an agent wants to do something above its authorized severity? It does not silently fail, and it does not barge ahead. It files an intent. An intent is a structured approval request, and it records the requesting agent, the approver, the exact action, the resource scope, the severity, and an expiry.
The approver gets a notification and approves or denies. The detail that makes this practical is that the runtime treats the approvable denial as control flow, not an error. The API says approval is required, the agent creates the intent, and then it observes the outcome asynchronously, continuing with whatever it is already allowed to do while it waits. Asking for permission does not stall the rest of the work.
Walk it through. A support-triage agent reads an incoming ticket, low severity, and runs. It drafts a reply, medium, and runs if the user authorized that far. It decides the right resolution is a refund issued to the customer, high severity, and stops. It files an intent naming the refund, the amount, the customer, the high severity, and an expiry, then moves on to the next ticket. When the manager approves, the intent unblocks that one refund, the agent issues it, and the approval is on the record. One pause, one approval, scoped to one action, with the rest of the work continuing around it.
Treating the approvable denial as control flow is what makes long autonomous runs viable. An agent working for hours will occasionally hit something above its ceiling. If that were an error, the run would fall over every time it needed a signature. Because it is a normal branch, the agent files the intent, keeps doing what it can, and picks the blocked thread back up when the approval lands. Needing a human does not mean failing.
An approval is bounded, not a handover
The most important property of an intent is what it does not do. An approved intent does not widen the agent's standing grants, and it does not hand the agent a copy of the approver's permissions. It creates one bounded authorization: this action, on this resource, at this severity, approved by this person, until this expiry.
The next time the agent wants to do the same kind of thing, it asks again. The approver delegated a single scoped operation, not their authority. It is the difference between lending someone your key for one door and handing them your keyring, and that difference is exactly what makes delegating to an agent safe to do at all.
Expiry matters as much as scope. A one-time approval that lived forever would quietly become standing authority, so the expiry window is what keeps a delegated action from turning into a permanent grant no one remembers giving. And because the intent is a record, an approver can see what they authorized and when, and a reviewer can see it later. Delegation you can read back is delegation you can govern.
The record knows who really authorized what
Because the intent stays attached to the action it authorized, the audit trail can answer a question that is otherwise very hard. When an agent did something sensitive, was it acting on its own standing authority, or on a human's one-time approval, and whose?
The trail distinguishes agent-owned authority from user-approved delegated authority, with the approver, the scope, the severity, and the expiry all on the record. After the fact, you can separate what the agent was always allowed to do from what a specific person let it do once, which is the kind of question a review actually turns on.
Why graduated trust beats a single switch
The alternative to all of this is a single switch: the agent is trusted, or it is not. That switch forces a bad choice. Set it to trusted, and a prompt-injected agent can send your data anywhere. Set it to untrusted, and the agent is a read-only toy.
Severity plus intents replaces the switch with a dial per action and a clean escalation path. The agent runs freely on the low-stakes majority of its work, and the human is in the loop exactly and only where the stakes are high. That is how you get an agent that is both useful and safe, rather than trading one against the other.
Freely on the small things, explicitly on the big ones
An agent worth deploying has to be able to act, and the dangerous actions are the point of useful work, not the exception to it. The way to allow them safely is not a master switch but graduated authority: classify by severity, let the user set how far the agent goes on its own, and give it a structured, bounded, audited way to ask for more. The agent asks for permission the way a good employee does, freely on the small things, explicitly on the big ones, and always with a record of who said yes.