Updated · 2026-07-04

Security settings

One team-wide switch: require an emailed 6-digit code before any destructive action (delete a VM, project, image, volume, or remove a member). Off by default — turn it on once an agent is acting on your behalf.

Superjolt has one team-wide security setting: email confirmation on destructive actions. When it’s on, anything that permanently deletes something pauses first and sends a 6-digit code to your email — the action only runs once that code is entered. It’s off by default.

What it protects

Most of what an agent does is reversible or cheap to redo — creating a VM, scaling it, restarting it, deploying again. Deletes are not. This setting is a guard against an irreversible delete firing on its own: a confused or runaway agent, or a leaked API token or browser session, calling destroy on your infrastructure without a human in the loop.

With the gate on, that human-in-the-loop step is forced, and the code lands in your inbox — so nothing gets deleted unless someone with access to your email signs off on it.

The actions it covers:

  • Delete a VM — destroy_vm
  • Delete a project — delete_project
  • Delete an image — delete_image
  • Destroy a volume — destroy_volume
  • Remove a team member
  • Admin only: remove a host, delete a user, delete a tenant

Everything else — creating, scaling, restarting, stopping, deploying — is never gated. (Stopping a VM isn’t destructive: it keeps your data and can be started again. See Backups & restore for what survives stop vs. destroy.)

Turning it on and off

In the dashboard: Settings → Security → “Email confirmation on destructive actions.” Only owners and admins can change it, and it applies team-wide — to every owner and admin on the team.

Or just ask your agent:

turn on email confirmation for destructive actions

The switch itself is never gated, so you can always turn it back off the same way — you’ll never lock yourself out of the setting.

What happens in the conversation

Say the gate is on and you ask your agent to delete a VM:

delete vm-abc123

  1. The agent comes back saying a 6-digit code was sent to your email (shown masked, e.g. j***@example.com) and asks you for it. Nothing has been deleted yet.

  2. Check your inbox. The email’s subject is like “Confirm: delete VM for api-prod (vm-abc123)”, and it spells out that the code expires in 10 minutes, can be used only once, and is scoped to that exact action on that exact resource.

  3. You give the code to the agent:

    the code is 481920

  4. The agent re-runs the delete with the code and it completes.

If the code expired or the email never arrived, ask the agent to send a fresh one:

resend the confirmation code

A new code is issued and the old one stops working.

In the dashboard, the same gate shows up as a dialog: click a delete button and you’re prompted to paste the code from your email before it goes through.

When to use it

Turn it on once an agent has standing access to your account — an always-on assistant, a scheduled or automated agent, or shared API tokens. That’s exactly the situation this guards: it’s the backstop that stops a runaway or compromised agent from bulk-deleting your infrastructure while you’re not watching.

It’s reasonable to leave off for solo, hands-on-keyboard use, where you’re the one issuing each delete and the extra email round-trip is friction with little added safety — or anywhere you can’t reliably reach your email mid-task.

It’s a straight tradeoff: protection against unattended deletes, against one email step per delete. Match it to how much your agent acts on its own.

Good to know

  • Off by default — new teams start with the gate open.
  • Team-wide — it’s a single switch for the whole team, not per-project or per-VM.
  • Code goes to the calling user — whoever’s session or token triggered the action gets the email, at the address on their account.
  • Rate-limited — a runaway loop can’t flood your inbox; only a few fresh codes are sent per minute and a handful per hour.
  • Audited — every code issued and every code used is recorded in your audit log (audit_list), alongside the delete itself.