Approvals

Agents run read-only by default. When an agent needs to do something sensitive, such as gaining elevated permissions in a cloud environment or making a change, it does not act on its own. It pauses the task and asks a human to approve. You stay in control of every sensitive action.

How an approval works

While working, an agent reaches a step that needs more than read-only access.
The task pauses and moves to the Approval required state. It does nothing further until a decision is made.
An authorized approver reviews the request. Each request shows the exact actions and resources involved, a short reason from the agent, and a risk level of Low, Medium, High, or Critical:
- Approve: the task resumes automatically and continues with the granted access.
- Reject: the task stops and reports that the permission was denied.

You do not have to be the person who started the task. Any authorized approver in the workspace can review and decide.

Automation policies

Not every request needs a human every time. Each environment has one setting, how much agents may do on their own, that decides which actions run unattended and which pause for approval, from Human-gated (every action waits for a person) through Supervised to Autonomous. Every action is rated for risk before it runs, and it goes ahead on its own when that risk sits at or below the level you chose. Workspace admins set this per environment. See Automation policies.

One exception holds on every setting, Autonomous included: actions rated Critical - deleting a database, wiping stored records, turning off a security control - always wait for a person. No configuration lets them run on their own.

The approval window

An approval is not a single-use token. Once a request is approved, the same task can reuse that approval for a limited time window without asking you again.

This matters because a task often needs the same access more than once:

It restarts or retries after a temporary failure.
Its short-lived access expires while a longer piece of work is still running.
You give it new input and it picks the work back up later.

In all of these cases, within the window, the task continues with the access you already approved, so you are not interrupted to approve the same thing twice.

The reuse is tightly scoped and time limited:

Same task, same scope. Only the task that received the approval can reuse it, and only for the exact actions and resources you approved. If the agent later needs something you did not approve, it raises a new request.
Time limited. The window lasts a short period (currently one hour). After it ends, the task must request a fresh approval. The credentials themselves are shorter-lived still - each set expires after 20 minutes, and the task mints fresh ones from the same approval as needed.
Starts on first use. The clock starts when the task first uses the approval, not when you grant it. An approval that waits a while for your sign off still gives the task the full window once it begins working.

How access is granted

When you approve a request, the agent receives temporary, scoped access to your environment. The access covers only the approved actions and resources, and it expires on its own after a short time. Credentials are generated on demand and are never stored.

The exact mechanism depends on the type of environment:

AWS: StratoNext uses temporary IAM role session credentials. Each session is limited to the approved actions and resources and expires automatically.
Other environments: each environment type uses its own equivalent of short-lived, scoped access. The principle is the same everywhere: least privilege, temporary, and never stored.

Auditing

Every request, decision, and use of an approval is recorded. You can see who requested what, who approved or rejected it, and when the access was used. This gives you a complete trail for review and compliance.