Approvals

7 min read

Approvals let you decide how independently an agent can work. When an action requires review, Kujira holds it before execution and shows it in the Approvals queue.

Open Approvals in Kujira

Define the degree of autonomy

In every agent's configuration, the proactivity system divides actions by the impact the agent estimates, from 0 to 100. The initial values are 70 to ask and 90 to block, but you can adapt them to each role.

0255075100

7090si no respondes en 10 min → sigue

Autónomo0 – 70

Actúa sin aprobación. Trabajo rutinario y reversible.

Pregunta y sigue70 – 90

Pide permiso; si no respondes, continúa con su propuesta.

Bloquea90 – 100

Espera una decisión humana antes de continuar.

The estimate depends on the model

An action's score is not a fixed classification: the agent itself estimates its impact before acting. It also decides whether an action belongs to an Always ask category. Use approvals as a supervision layer based on its reasoning; to block a capability deterministically, disable it in Behaviour.

You also set the middle band's timeout per agent. Use it to keep work flowing for reversible decisions; blocking actions do not run until a person resolves them.

Actions that must always be reviewed

Alongside thresholds, Always ask lets you define categories that require approval regardless of the level the agent estimates. It is the right protection when the type of action matters more than its specific context.

Start from the configuration suggestions and tailor them to your case:

• Spending money or accepting a cost.
• Deleting or overwriting data.
• Sending external communications or publishing content.
• Installing tools or modifying infrastructure.
• Sharing credentials.
• Making commitments to third parties.

An approval authorizes only the specific decision presented. It does not make a similar action permanently allowed.

What the decision maker receives

Each request includes a title, a summary of what would change, and the impact identified by the agent. When it needs more context, it can attach details so you can review the plan before responding.

The agent requests a decision

The request appears in the Approvals queue and, when it comes from a chat, is linked to the conversation so you can understand the context.

You review and decide

You can approve or reject an action. If the agent needs judgement rather than permission, it can ask a question with options or allow an open response.

Kujira delivers the result

The agent receives the decision in its conversation and continues, changes its plan, or stops according to your instructions.

For middle-band judgement requests, the agent can suggest a fallback option. If nobody responds before the timeout, that option is applied; if no safe option exists, the question expires and the agent decides with the information available. Blocking questions wait for a person.

By default, no request stays pending for more than 7 days, whatever its band. It is a platform-wide limit set by the Kujira team. A middle-band fallback is applied earlier, when its timeout ends; anything still unanswered at that limit simply expires: it is never approved and the fallback is never applied, and the agent neither carries out what it asked for nor picks an answer to the question on its own. If it still needs one, it asks again. The only exception is the expired Claude credential notice, which closes when the credential is renewed.

You don't have to click an option. You can answer by writing in the conversation, with the text of an option or in your own words; the agent records that answer and the question is closed. If the conversation changes and the question no longer makes sense, the agent withdraws it. In the chat, the buttons are replaced by the reason.

Who can resolve them

To approve, reject, or answer a request, you need the approval.resolve permission. View permission lets you see the queue, but not decide for the organization.

Action	Permission
View the approval queue	approval.view
Approve, reject, or answer a request	approval.resolve

You only see requests from agents you have access to. Those from a direct chat belong to that person, like the chat itself: besides them, only the channel's alert recipients see them. Owners and administrators don't, except for configuration changes they have to decide.

Outside a direct chat, a request to do something (not a question) is only seen and decided by whoever manages the agent, the person who made the request (through a scheduled task of theirs or through another agent), the channel's alert recipients, and owners and administrators. With chat-only access to the agent you don't see other people's requests. Questions can still be answered by anyone who reaches the agent: answering is not authorizing.

The first valid decision resolves the request. Its result is reflected in the queue and delivered to the agent once, even if several people were reviewing it simultaneously.

Approval and capability are separate controls

An approval reviews an action the agent can attempt. To prevent it entirely, disable the corresponding capability in Behaviour. For example, blocking the credential capability prevents its use; requiring approval lets it be requested case by case.

Configuration changes requested by an agent

Some tools let the agent change its own configuration: its memories and skills, its scheduled tasks, credentials, MCP servers, its configuration (today, the avatar), and linking devices. What happens depends on who gives the order. Settings > Security > Unattended mode shows the full scope in a table:

Affects	Operator	Unsupervised	External contact
Memories and skills	By permissions	Automatic / Manual / Deny	—
Scheduled tasks	By permissions	Automatic / Manual / Deny	—
Credentials	By permissions	Manual / Deny	—
MCP servers	By permissions	Manual / Deny	—
Agent configuration	By permissions	Manual / Deny	—
Link devices	By permissions	Manual / Deny	Manual

• Operator: if the order comes from an identified operator (in the panel, the app, or a channel with their verified account), or from something that operator set going (a scheduled task of theirs, or a request their agent passed to another), the agent only does what that person could do from the panel. Without the permission, an approval is requested. No setting changes this.
• Unsupervised: the order does not come from an identified operator. This covers messaging and email channels when whoever writes is not an identified operator, events (webhooks, GitHub, Google Drive, Google Calendar), scheduled tasks with no creator and conversations between agents that no operator asked for. Automatic makes the change, Manual waits for someone to approve it, and Deny neither makes it nor asks: the agent knows from the start of the turn and, if asked, replies that it can't be done from there. With Deny on memories it doesn't write its own memory either. Credentials, MCP servers, agent configuration and devices have no Automatic.
• External contact: with an Agent Desk customer the agent changes nothing about itself. It can only ask to link that customer's machine, always with approval.

New organizations start with every cell on Manual. Each channel can set its own in its details (Inherited or any of the above); scheduled tasks and conversations between agents always follow the organization's. Changing them, for the organization or a channel, requires permission to edit the organization, and is recorded in the activity log.

An operator with chat-only access does not change the agent's memory: what they want for themselves goes to their private notes and the agent applies it from then on; anything meant for everyone waits for approval from whoever manages the agent. They cannot ask it to archive or reorganize its memory either.

When an approval is needed, the card shows what changes, where the order came from and why it needs approval. A notification does not approve it directly: it opens the card for review. These approvals can only be decided by someone who could make the same change from the panel: the matching permission (for example cronjob.delete to delete a scheduled task) and management of the agent. When you approve, the change is applied in your name. They do not expire for lack of an answer beyond the general 7-day limit, and are never approved on their own.

Design a practical policy

Start by letting the agent resolve routine work, and use mandatory rules for anything with external, financial, or irreversible impact. If a queue builds up too many decisions, reduce mandatory categories or raise the ask threshold; if the agent takes unnecessary risks, do the opposite.

Also review Notifications to ensure pending requests reach the right people.