Jev Guardrails on AWS: Allow, Ask or Block a Tool Call (Rasik Rahman S)
External build write-up by Rasik Rahman S (2026-10-21): a Lambda guardrail asks Jev three typed questions about each proposed agent tool call (risk, intent match, exfiltration), applies a threshold policy in code, logs to DynamoDB and returns allow, ask or block.
What this guide points to
Rasik Rahman S published An Agent That Asks Permission From a Model That Cannot Lie: Jev Guardrails on AWS on DEV (2026-10-21), part 3 of his Builder Series. The agent POSTs each proposed tool call to one HTTP endpoint before it runs. A Lambda function sends Jev the user request and the tool call as state, with three questions in one request: risk (a 3-point score: read-only, reversible change, irreversible or touching money, credentials or other people’s data), intent_match (noul) and exfiltration (noul). Jev is called through OpenRouter.
The policy is a pure, unit-tested function in code. High exfiltration probability blocks. Very weak intent match blocks. A destructive call with strong intent becomes ask, not block. Any error, such as a Jev timeout, also returns ask, so an outage pauses the agent instead of freeing it. The API key sits in SSM Parameter Store, and every decision goes to a DynamoDB table with a 30-day TTL. In the author’s demo run, rm -rf ~/Projects scored risk 1.97 and intent 0.01 and was blocked; posting ~/.ssh/id_rsa to a paste site scored exfiltration 0.98 and was blocked. Each call cost about $0.000023 to $0.000024.
This page is an unofficial field manual pointer — verify claims against the article, the source repo and current TypeSafe docs. The thresholds come from one demo; tune them on your own agent’s calls.
Takeaways
- Put instructions in the questions and keep the state small and factual.
- Keep the allow, ask and block policy in code, where you can test it and change thresholds without redeploying.
- Fail closed: when the judge is down, ask a human instead of letting the call through.