SLAUNT / SAFETY

Guardrails,
by default.

Agents are powerful employees with no fear of consequences. Slaunt wraps every run in budget caps, scoped tools, human approval, and a kill switch that actually kills.

1.0

Five guardrails on every run

Not a policy document — enforcement. Each layer is on from the first run, and each one holds on its own.

slaunt — spend limits
oAuth Tasked AgentLIVErun #2041 · budget guard on
Spend
$3.96of $4.50 cap

At the cap the run pauses and asks. It never spends past it.

slaunt — spend limits
oAuth Tasked AgentLIVErun #2041 · budget guard on
Spend
$3.96of $4.50 cap

At the cap the run pauses and asks. It never spends past it.

2.0

Rules we don't bend

The guardrail stack follows four principles. They're design decisions, not settings.

Deny by default

An agent starts with nothing — no tools, no spend, no reach. Everything it can do is something someone granted.

Human in the loop

Guardrails don't slow work down; they decide which work needs a person. Everything else flows.

Kill means kill

A stop control that negotiates isn't a stop control. Kill halts the run — cleanup questions come after.

Written down

Every action lands in the audit trail as it happens. If it isn't logged, it didn't run.

3.0

Guardrails agents can read

Limits that live in a PDF get ignored. In Slaunt, an agent's scope is part of its context — it knows its caps, its tools, and its org boundary before it acts.

Every request an agent makes is bound to an authenticated identity and an organization scope. The agent can query its own limits the same way it queries workspace memory — which is why a Slaunt agent stops at a constraint instead of discovering it in an incident review.

Run scope · resolved before the first tool call
identityauthenticated · required
org scopebound to your organization
tool grantsexplicit, per run
spend capset by your workspace
auditalways on

Run agents you can trust

Budget caps, scoped tools, approval gates, and a kill switch — on every run, from the first one.