ADEStay in charge

Agents do the work.
People decide what ships.

Every agent acts for a person, inside that person’s rights, with tokens that expire within the hour. Every write is a plan. Production, money and access wait for a person with a passkey; budgets stop work before it spends; and one switch suspends every agent in the organization.

00 · An approval, as the approver sees itFig. 1 · product UI, demo organization
Fig. 1: an approval, as the approver sees it. Product UI, demo organization.
A
Who asked, for whomKenji S., through a coding agent on a laptop, calling one tool: the whole chain is on the record.
B
Why it needs a personDestructive tools always wait for a person, by an organization rule; the agent’s ceiling only lets it ask.
C
Exactly what happensThe plan, step by step, with its write modes and its hash. Nothing outside it can run.
D
Approve with a passkeyStep-up if you last confirmed more than 10 minutes ago; if the target changes first, the plan is void.
01 · ApprovalsFig. 2

Approvals pinned to the plan.
Not to a chat message.

One approvals engine sits behind every change a person must allow: production deploys, agent writes, access, quota increases, secret versions. An approval names the exact plan, and only that plan can run.

Fig. 2Plan, approve, apply: what an approval is pinned to
02 · Budgets and capsFig. 3

Budgets stop before they spend.
And never delete anything.

Budgets nest from the project down to a single task, and each one is checked before the next call. A model call reserves the most its reply can cost before it runs, so agents stop at their budget instead of running past it. Other usage is checked every few minutes and pauses at the cap.

Fig. 3Nested budgets, and how a model call is reserved against themdemo amounts

When a cap is reached

Workloads on your servers
Never stopped. Only new billable items are refused
Agents, runners and model calls
Paused: agent sessions suspend, runner jobs stay queued, model calls are refused with a plain message
Serverless endpoints
Scale to zero; requests get a plain message
Storage and data
Keeps serving. Nothing is deleted
Alerts
At 50, 90 and 100 %, and on the forecast
Lifting a cap
A billing admin, with a reason. Never an agent
03 · Guardrails in the LLM gateway

One door to every model.
With guardrails on it.

Sessions, agents, boxes and services reach models only through the Frazer LLM gateway, with short-lived keys. Guardrails run before any cache lookup, and a key can only choose a stricter policy than its project.

Guardrails in the LLM gateway: each check, when it runs and what it does by default
CheckWhenDefault
Secrets in promptsbefore the callBlocked; the value is hashed, never stored
Personal databefore the callMasked, and restored in the reply
Prompt injection in tool results, pages and ticketsbefore the callLabeled; blocked above 0.9 for agents that can write
Secrets in repliesin the replyRedacted, also while streaming
Data policyper requestBlocked if a step could reach a provider that keeps or trains on data
Cost per requestper requestBlocked above a limit, $2.00 by default, with the estimate shown

Logs keep metadata only by default. Zero-retention mode is set per project. Keys never approve anything.

04 · Grants and SecretsFig. 4

Agents act for you.
Never as you.

An agent can only do what its ceiling, your rights at that moment and its token all allow, minus anything denied. It never holds a stored credential: secrets reach it as references through the credential broker, and people can write a secret but not read it back.

Fig. 4What an agent may do, checked on every request

Nothing long-lived

Box connection
one hour, bound to the person, the box and the device
SSH certificate
eight hours
Model token
an hour at most, per box or per session
Agent task token
an hour at most, for one audience
Just-in-time access
up to eight hours, with a reason and approvers
A revoke
applies on the very next request

A new agent starts with a read-only ceiling; a coding agent starts at draft pull requests. Every secret read is audited, and break-glass access is always reviewed by a second person.

05 · Audit

Every write is on the record.
Who, for whom, and why.

People, agents and Frazer itself act through the same API, so every write is a plan with an audit entry, and every decision has an ID you can explain later: the rule that allowed or denied it, as policy stood at that moment.

Audit logacme-staging
10:52:04  plan.create     actor=agent:frazer-agent  on_behalf_of=user:lena  via=mcp  plan=sha256:9b1e…c04d
10:53:40  approval.grant  actor=user:noah  approval=apr_01JA3KQ7  step_up=passkey
10:53:41  plan.apply      actor=user:lena  for=agent:frazer-agent  decision=dcs_7f2c  result=ok
10:58:12  tool.denied     actor=agent:alert-tuner  permission=secrets.versions.access  denied_by=principal_boundary
Fig. 5An agent’s change, approved and applied, and a denied tool call, as they appear in the audit logdemo organization
06 · Kill switchFig. 6

One switch stops every agent.
Smaller ones stop less.

Kill switches come in sizes: an item, a wave or a whole run; one agent, a squad or a campaign; or every agent in the organization at once. Runs trip their own switch when the numbers go wrong.

Fig. 6Kill switches by scope
07 · Who may do what

Who may do what.
Written down, not implied.

Roles are explicit: no basic role implies access administration, token minting or reading secrets. Agents get the narrowest column of all.

Who may do what: each action, for developers, approvers, org admins, billing admins and agents
You, as a developerApproversOrg adminsBilling adminsAgents
Start sessions and fan-outsallowed: 100 at a timenot their joballowed: set the limit, up to 1,000not their jobwithin limits: sub-agents, two levels
Propose a changeallowed: as a plannot their joballowed: as a plannot their joballowed: always as a plan
Approve a plannever: never their ownallowed: with a passkeywithin limits: when namednot their jobnever: never
Apply to productionallowed: after approval, step-upnot their jobnot their jobnot their jobnever: never
Merge to the default branchallowed: yesnot their jobnot their jobnot their jobnever: drafts only
Grant accesswithin limits: only what they holdnot their joballowed: with IAM adminnot their jobnever: never
Set budgets, lift a capnot their jobnot their jobnot their joballowed: with a reasonnever: never
Change guardrails and approval rulesnot their jobnot their joballowed: yesnot their jobnever: never
Read a secret’s valuenever: write-onlynever: write-onlynever: write-onlynever: write-onlynever: references only
Suspend all agentsnot their jobnot their joballowed: from Security or IAMnot their jobnever: never
  • allowed
  • within limits
  • never
  • — not their job
08 · What an agent may never do

What an agent may never do.
However it is asked.

These are not settings an agent can talk its way around. They are enforced by Frazer, outside the agent’s sandbox, on every request.

  • Approve anythingnot a plan, not a grant, not its own work
  • Grant accessor hold more than the person it acts for
  • Change the rulesbudgets, limits, guardrails or its own hiring policy
  • Lift a cap or a quarantineor reset a kill switch
  • Hold a stored credentialor read a secret’s value; it gets references
  • Verify its own worka verifier from another model family does
  • Write the numbers it is measured bykey results come from your sources
  • Take another agent’s word as approvalagent-to-agent messages are untrusted
  • Merge, or write live to production from a runpeople merge; production is a plan
  • Buy serversor spend past a budget
The ADE

Keep going.

  • How it works

    One piece of work, from a prompt to production, in eight steps on the real screens.

  • A thousand sessions

    Fan-out, waves and budgets, where sessions run, and how results come back.

  • Tour

    Twelve screens of the Frazer app, and every way into the ADE.

Let agents do the work.
Keep the decisions.