Approvals

Reads run freely. Writes don't: every write to a system of record stops at an approval gate before it commits.

A write pauses the job for approval

When the agent decides to call a writing tool — update a Sheet, change a record in S/4, send an email, create an issue, run a SQL UPDATE — it pauses. The user sees:

  • What tool will be called.
  • The exact inputs (the diff — what's being changed, from what to what).
  • Why the agent decided to do it (the reasoning).

The user clicks approve or reject. Only after approve does the call execute.

To change what's proposed, say so — "yes, but bump the quantity to 50 not 47" — and the agent re-drafts. The new diff comes back through the same gate.

A write is any mutation outside Daslab

Examples of gated tools:

  • gmail.send, slack.post_message, outlook.create_event
  • sheets.update_values, teams.post_message, sap_s4hana.odata.PATCH
  • postgres.execute_sql when the SQL is INSERT|UPDATE|DELETE
  • File writes, deploys, infra changes
  • sap_s4hana.bapi.update_* and any ABAP run that mutates state

Tools declare their write-shape in their definition. Read tools (.search, .get, *.list, SELECT) skip the gate.

Reads and sandbox runs flow freely

  • Reads of any kind. The agent can search, query, list, fetch all day. No friction.
  • Writes inside Daslab — creating a scene, adding a connection, anything to do with cells: adding, moving, resizing, re-viewing. Cells are views on assets, and rearranging views doesn't gate.
  • Sandbox writes. When the agent writes its own code and runs it, the code runs in an isolated sandbox where it can't touch external systems. The sandbox itself is torn down after.

Approve a batch at once, or stage it by role

Related writes group into a single approval — "approve all 47 of these" — one look, one decision, each write still individually recorded. Scenes that need a second pair of eyes stage it instead: the agent drafts, a reviewer with the approval role signs off, then it commits.

Auto-approve is per scene, per job, or per tool

Some workflows are routine enough that gating every write adds no safety. Auto-approve switches on at the level you choose: a whole scene (its jobs run unattended), a single job (the rest of the scene stays gated), or per-tool rules with thresholds — "writes to this Sheet under $1,000 pass; over, prompt me." The record keeps the distinction either way: an auditor can always see which approvals were human and which were automatic. The default everywhere is that you look first.

Safe to point at production

The first question every IT and security team asks about an AI agent: what stops it from doing something destructive? The approval gate is the answer — combined with the audit trail and permissions inherited from the source, it's why Daslab can be pointed at production systems on day one, not just at sandboxes.

What's next

  • Audit — what gets logged.
  • Auth — permission inheritance from connected accounts.

Updated 2026-04-30