Approvals and audit

Your agents work on their own, but never blind. Actions with a real-world effect wait for your sign-off, spending caps stop runaway use automatically and what happens is recorded. Human-in-the-loop governance is what lets you delegate without losing control.

What waits for your approval

An agent can reason, search and draft on its own, but when an action is irreversible or has an external effect, it stops and leaves it in the Approvals inbox. Nothing runs until a person with the right role says yes. These are the categories that go through review:

• External communication: sending an email, replying to a client, posting to a channel or social network, or any message that leaves your organization.
• Money movements: ordering a payment, issuing or changing an invoice, approving an expense or a transfer.
• HR decisions with an effect: approving time off, contract termination, bonuses or payroll.
• Changes to critical data: deleting clients, emptying tables, changing global settings or touching records that can’t be recovered.
• Sensitive tool calls: calls to external tools outside what was marked safe in advance.

Each tool that acts outside Shara is marked in the product as requires approval; the agent cannot skip that mark.

What does not need approval: reading, searching, summarizing, analyzing, drafting or preparing proposals. Speed is kept for everything reversible; the brake only appears where there are consequences.

The deciding rule is simple: if the action changes something outside Shara or can’t be undone, it goes through you. A sales analysis runs on its own; the email that analysis proposes to send does not. Amadeus orchestrates and delegates to the specialists, but none of them, not even Amadeus, can skip this control.

Approval cards

Each request lands in the inbox as an approval card. The card tells you at a glance what kind of action it is and carries the relevant information:

Card	What it represents	Data it shows
Outgoing email	An email ready to be sent to an external recipient.	Recipient, subject, body (editable), requesting agent.
Payment / invoice	A money movement or the issuing of an invoice.	Amount, payee, description, method.
Post	A post or message for a channel or social network.	Channel, content, attachments.
Client reply	The answer to an incoming ticket or inquiry.	Thread, draft reply (editable).
Tool / connector	An action on a connected tool.	Tool, parameters, expected effect.
Critical data	An irreversible deletion or change to your data.	Affected resource, scope.
HR decision	Time off, bonus, contract termination or another personnel decision.	Employee, decision type, agent.

Severity and time limits

Each card carries a severity (high, medium or low) that orders your inbox, set by the type of action. Payments and outgoing emails are high; client replies and posts are medium; the rest are low. The inbox sorts by severity and age, so what is urgent rises to the top.

There are two different clocks, and it is worth keeping them apart:

1. Expiry: up to 7 days. A request an agent raises waits for your decision. After 30 minutes the conversation goes on hold, for up to 7 days: when you decide (even the next day, from another screen), the agent carries on where it left off, in the same conversation. If nobody decides within that time, the request expires and the action does not run. Silence equals a no: nothing runs “by default”. If it still makes sense, the agent has to ask again.
2. Attention window: from 10 to 120 minutes, by type. Each type of request has a reasonable time for a person to react. When it passes without a decision, Shara sends a notice so someone attends to it.

Type of request	Attention window
Tool call	10 minutes
Reply to a client	15 minutes
Outgoing email	30 minutes
Calendar event	30 minutes
Post, newsletter or other publication	60 minutes
Any other type	60 minutes
Payment order	120 minutes

A send that follows a draft you already approved (for example, the email after the approved draft) is approved automatically if it comes within a short window, 5 minutes, so you are not asked twice for the same thing.

The approvals inbox

Each request shows which agent is asking (for example, Patterson for a commercial offer or Graham for a payment), the action described in natural language, the context that prompted it and its severity. You decide with two buttons: Approve or Reject. Whoever decides leaves a trace in the audit log. If you have two-step verification turned on, approving an action also requires the second factor (or a passkey sign-in), like the rest of the application.

When you reject, you can (and should) leave a reason. That comment goes back to the agent so it doesn’t blindly repeat the attempt, and it helps you improve the IDENTITY.md rules. A well-explained “no” makes the next proposal better. You can also decide many cards at once, or a whole group of related cards.

Accept-edit mode

For actions that produce content (an email, a post, the reply to a ticket) you don’t just approve or reject: you can edit the proposed result before accepting it. You correct the tone or a detail and Accept the final version, or Reject and send the work back to the agent with your comment. What runs is the version you reviewed and approved.

Who can approve what

The ability to decide depends on each person’s role. The full list is in Roles and permissions.

Role	What they can decide
Owner and Administrator	Every request in the company.
Director	The requests delegated to them and the requests of agents of their own department.
Operator, IT and Viewer	Nothing. Their sensitive actions go to the director of the department, or to the owner and administrators if there is no director.

An approval is a personal act: it needs a signed-in session of a person. An API key cannot approve anything, by design. The record always shows who approved, not “the system”.

An end-to-end example

Imagine you ask Amadeus to close out the support week and write to the clients with the most incidents. Wanamaker (customer service) summarizes the tickets (a reversible action: it runs on its own) and drafts three follow-up emails. Those emails are not sent: they show up in your inbox as three Outgoing email cards.

1. You open the first card: you see recipient, subject and body, with the context.
2. You fix a sentence in the body and Accept. The email goes out with your version.
3. The second one seems unnecessary to you: you Reject with the reason “this client already closed by phone”. Wanamaker notes it.
4. You leave the third one for later. If nobody decides, the conversation stays on hold for up to 7 days; after that it expires and nothing is sent.
5. Every decision is left in the audit log with your name.

Spending caps

Beyond your manual review, three spending caps stop execution without human intervention as soon as they are exceeded. They protect against an unexpected loop, a malicious prompt or a badly calibrated task. They are measured in STU:

Cap	Default	What it cuts
Per run	1 M STU in one run	Cuts that run. Prevents a single task from running away.
Per hour	10 M STU in the last 60 minutes	Pauses inference while the rolling window stays high.
Per day	80 M STU in the last 24 hours	Pauses inference while the rolling window stays high. It is the hard cap.

An owner or administrator can edit the three values or switch any of them off, in Settings → Limits & alerts. The hourly and daily caps lift on their own when their window drops below the threshold; the per-run one, after an hour. An administrator can lift a cap earlier, or leave a manual pause that doesn’t lift on its own.

When a cap trips, the API answers 429 kill_switch and the administrators get a notice. The caps are defense, not billing: a halted run does not charge you extra. For usage alerts, the same screen lets you choose when to be warned about your quota (by default at 80%, 90% and 100%). See STU and quotas.

Audit log

The audit log records what happens in your company, so you can show who did what. Each record has these fields:

Field	Meaning
id	Unique id of the record.
tenantId	Your company.
actorUserId, actorName, actorEmail	Who did it (empty if the system did it or the person no longer exists).
action	What happened, for example identity.patch.
resource, resourceId	What it happened to.
before, after	The state before and after the change.
createdAt	When.

{
  "id": "5b0c8d2e-7a41-4c1f-9d3e-2f6a1b9c0e55",
  "tenantId": "c2a9…",
  "actorUserId": "7d41…",
  "actorName": "Marta Ruiz",
  "actorEmail": "marta@example.com",
  "action": "identity.patch",
  "resource": "agent_identity",
  "resourceId": "patterson",
  "before": { "length": 1280, "hash": "9f2c1a7b", "version": 14 },
  "after": { "length": 1342, "hash": "3e7d5c10", "version": 15, "mode": "append", "reason": "Lower the discount threshold" },
  "createdAt": "2026-07-11T10:42:07.000Z"
}

The contents of before and after depend on the action. For identity changes they hold a summary (length, a short hash and the version) instead of the whole text.

Only owners and administrators can read it, with GET /audit (filters: type, actor, resource, resourceId, from, to, limit and cursor).

Verifying the chain

Each record carries the SHA-256 hash of the previous one, forming a chain. GET /audit/verify-chain walks the chain (up to 200 records per call by default) and answers with a status (intact, broken or empty), the number of valid and invalid records and, if there is a problem, the first record that does not add up. If someone alters a record in the middle, the check detects it.

The database only allows records to be added: modifying, deleting or emptying the log is rejected, even for the application itself. On top of that, the chain proves that history was not changed afterwards; it is a check you can run yourself, not a promise. The rule is not absolute: a database administrator with maximum privileges could bypass it, but it would not go unnoticed: every hour a signed copy of the last line of each company’s chain is stored in storage with a 30-day deletion lock, outside the database, and every day the database is checked against those copies. The audit log lives in the EU.

More context on the security layers, roles and compliance in Security and compliance.