--- title: "Stay in charge of your agents · Frazer" description: "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; one switch suspends every agent." url: https://frazer.ai/ade/control index: https://frazer.ai/llms.txt tokens: 2826 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Stay in charge of your agents · Frazer **ADE** Stay 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. [Start building](https://frazer.ai/start?product=app) [Security and trust](https://frazer.ai/security) 00 · An approval, as the approver sees it Fig. 1 · product UI, demo organization *The Approvals page of the demo organization Acme: Kenji S.’s coding agent asks to delete the staging database acme-reports-old. The approver sees who asked and for whom, why it needs a person, the five-step plan with its hash, and Deny or Approve and apply, with who is asked and the decisions of the last 30 days beside it.* Fig. 1: an approval, as the approver sees it. Product UI, demo organization. A **Who asked, for whom** Kenji S., through a coding agent on a laptop, calling one tool: the whole chain is on the record. B **Why it needs a person** Destructive tools always wait for a person, by an organization rule; the agent’s ceiling only lets it ask. C **Exactly what happens** The plan, step by step, with its write modes and its hash. Nothing outside it can run. D **Approve with a passkey** Step-up if you last confirmed more than 10 minutes ago; if the target changes first, the plan is void. 01 · Approvals Fig. 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. *Plan, approve, apply. An agent proposes a tool call in validate-only mode, so nothing changes yet. The plan is the exact diff, pinned to the target’s version and named by its hash. The approval comes from a role, a group or a name: n of m, never the requester, with a passkey in the last 10 minutes; agents and service accounts never approve, and production and protected resources need four eyes. Apply runs exactly this plan: a changed target voids it, and it expires after 15 minutes. The audit keeps one decision ID with both identities: who, on whose behalf, and why. Approvals are routed to the Inbox, email, Slack and the app, and never approved from a chat message.* **Fig. 2** Plan, approve, apply: what an approval is pinned to 02 · Budgets and caps Fig. 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. *Nested budgets, each checked before the next call: the project acme-staging at $5,000 a month, the squad platform-ops at $60 a day, the objective calm on-call for Q4, the campaign alert-hygiene at $300, and one task at $4 (demo amounts). A model call is reserved against the organization, the project, the key and the session: at admission the gateway reserves input tokens at the input price plus the most the reply could cost, and settles to the real cost when the reply ends. An admitted stream is never cut off halfway; a per-key limit on parallel calls keeps reservations inside the budget.* **Fig. 3** Nested budgets, and how a model call is reserved against them demo 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 | Check | When | Default | | --- | --- | --- | | Secrets in prompts | before the call | Blocked; the value is hashed, never stored | | Personal data | before the call | Masked, and restored in the reply | | Prompt injection in tool results, pages and tickets | before the call | Labeled; blocked above 0.9 for agents that can write | | Secrets in replies | in the reply | Redacted, also while streaming | | Data policy | per request | Blocked if a step could reach a provider that keeps or trains on data | | Cost per request | per request | Blocked 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 Secrets Fig. 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. *Three overlapping circles: the agent’s ceiling, lena’s rights right now, and the token’s scope. What the agent may do is the part all three share, minus anything denied, checked on every request.* **Fig. 4** What 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 log acme-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. 5** An agent’s change, approved and applied, and a denied tool call, as they appear in the audit log demo organization 06 · Kill switch Fig. 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. *Kill switches by scope. A fan-out stops by item, by wave or as a whole run, and a run trips on its own above 25 % failed after 20 items, on a broken guardrail, at the budget, or after 30 minutes without progress. Agents stop one at a time, by squad or by campaign; quarantine keeps the evidence and a manager can never lift it. Suspend all agents stops everything: every agent token stops working on the next request, and keys of a kind stop in one write. Each switch is reset by the person who owns it, and every trip is on the record.* **Fig. 6** Kill 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 developer | Approvers | Org admins | Billing admins | Agents | | --- | --- | --- | --- | --- | --- | | Start sessions and fan-outs | allowed: 100 at a time | not their job | allowed: set the limit, up to 1,000 | not their job | within limits: sub-agents, two levels | | Propose a change | allowed: as a plan | not their job | allowed: as a plan | not their job | allowed: always as a plan | | Approve a plan | never: never their own | allowed: with a passkey | within limits: when named | not their job | never: never | | Apply to production | allowed: after approval, step-up | not their job | not their job | not their job | never: never | | Merge to the default branch | allowed: yes | not their job | not their job | not their job | never: drafts only | | Grant access | within limits: only what they hold | not their job | allowed: with IAM admin | not their job | never: never | | Set budgets, lift a cap | not their job | not their job | not their job | allowed: with a reason | never: never | | Change guardrails and approval rules | not their job | not their job | allowed: yes | not their job | never: never | | Read a secret’s value | never: write-only | never: write-only | never: write-only | never: write-only | never: references only | | Suspend all agents | not their job | not their job | allowed: from Security or IAM | not their job | never: 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 anything** not a plan, not a grant, not its own work - **Grant access** or hold more than the person it acts for - **Change the rules** budgets, limits, guardrails or its own hiring policy - **Lift a cap or a quarantine** or reset a kill switch - **Hold a stored credential** or read a secret’s value; it gets references - **Verify its own work** a verifier from another model family does - **Write the numbers it is measured by** key results come from your sources - **Take another agent’s word as approval** agent-to-agent messages are untrusted - **Merge, or write live to production from a run** people merge; production is a plan - **Buy servers** or spend past a budget The ADE ## Keep going. - ### [How it works](https://frazer.ai/ade/how-it-works) One piece of work, from a prompt to production, in eight steps on the real screens. - ### [A thousand sessions](https://frazer.ai/ade/sessions) Fan-out, waves and budgets, where sessions run, and how results come back. - ### [Tour](https://frazer.ai/ade/tour) Twelve screens of the Frazer app, and every way into the ADE. ## Let agents do the work. Keep the decisions. [Start building](https://frazer.ai/start?product=app) [Tour the app](https://frazer.ai/ade/tour)