Use Cases / agent-safety
Jev Agent Safety
Agents can call shell, payments, or delete APIs. You need a fast yes/no risk gate — not a long chat completion — before each tool.
Try a related template free on this host — 5 anonymous real-API runs with no signup — then ship the same schema with a prepaid jv_live_ key. See is Jev free? and playground.
Why Jev
Noul and score primitives give calibrated risk you can threshold (allow / confirm / block) in tens to hundreds of milliseconds. Pass the planned tool name + args summary as state; branch in code on the typed answer. Example: shell rm -rf /workspace → high risk Score + block Choice before execution.
How to define the decision
State should include tool name, argument summary, and optional user intent. Ask a Choice for allow / confirm / block plus a Score or Noul for risk. Keep the label set identical to what your agent runtime understands.
When to use Jev
- Pre-tool-call risk gates
- Confirm-before-send for destructive actions
- Policy checks on agent plans
When not to use Jev
- Replacing sandboxing and least-privilege IAM
- Generating safer code patches
- Unbounded multi-hop security audits
Sample input and output
From the live tool template. Run it in the playground for a real API response — sample labels below are illustrative until you click Run.
Input
goal: Clean up the build directory tool: bash arguments: rm -rf ./dist && aws s3 sync ./build s3://prod --delete context: CI deploy step
Sample display fields
- action: block · 84%
- risk: 0.84
Block or low-confidence → pause and require operator confirm. Allow only when risk is clearly below your bar. Model scores never override hard IAM denials or sandbox escapes.
Failure modes and human fallback
- Upstream or network errors: retry with backoff; do not invent a decision.
- Low confidence: route to a human queue or safer default — never auto-act on money/destructive tools.
- Schema drift: keep a golden fixture set in CI so label changes fail the build before production.
- Jev is a soft policy gate — not a replacement for sandboxing or least privilege.
- Destructive money/shell tools must keep a hard deny list in code.
- On API failure, fail closed (do not execute the tool).
API example
Same prepaid jv_live_ balance as tools. Output tokens are free on this host's metering model.
curl https://jevtypesafe.org/api/v1/decide \
-H "Authorization: Bearer jv_live_YOUR_KEY_HERE" \
-H "Content-Type: application/json" \
-d '{"state":"Agent tool proposal\nGoal: Clean up the build directory\nTool: bash\nArguments: rm -rf ./dist && aws s3 sync ./build s3://prod --delete\nContext: CI deploy step","questions":{"action":{"type":"choice","instructions":"Should this tool call be allowed, require confirmation, or blocked?","criteria":{"allow":"safe to run automatically","confirm":"needs human confirmation","block":"too risky — refuse"}},"risk":{"type":"score","instructions":"Overall risk of irreversible harm or data exposure (0–3 scale).","criteria":["negligible","moderate","high","critical"]},"destructive":{"type":"noul","instructions":"Is this destructive or irreversible?"},"external_side_effect":{"type":"noul","instructions":"Does this have external side effects (cloud, email, payments)?"},"data_exposure":{"type":"noul","instructions":"Could this expose sensitive data?"}}}'FAQ
- Which tool should I open first?
- Start from Command Safety (Agent Risk) in Tools, or wire custom questions on /api/v1/decide with allow/confirm/block choices.
- What is the human fallback?
- On block or low confidence, pause the agent and surface a confirm UI to an operator. Never let a soft model score override hard IAM deny rules.
Related use cases
Ready to build?
Free anonymous tool runs, then prepaid packs and a jv_live_ key — independent host, not affiliated with TypeSafe AI.