# AI Agent Guardrails with Jev: Fast Checks | QQuantum.ai > AI agent guardrails from fast Jev checks: screen inputs, test retrieved evidence and review tool actions before they run, while your code owns permissions. Source: https://qquantum.ai/technology/jev/agent-guardrails [Home](https://qquantum.ai) [technology](https://qquantum.ai/technology) [jev](https://qquantum.ai/technology/jev) agent-guardrails Jev use case · Agent guardrails # Let agents act. Keep the checks. AI agent guardrails are the checks that run around an agent: on what it reads, the evidence it cites and the actions it proposes. With Jev, each check is a focused, fast judgement. This is for teams letting agents act in real systems. Your application still owns permissions, approval rules and what happens when a check is uncertain. Design your agent checks Proposed integration pattern · Evaluate on your own traffic All Jev: AI Tools & Fast Decisions → Introduction transcript. Qubi: An agent that can act needs a second look before it reads, answers or acts. Incoming text is screened for hidden instructions, and stays labelled as untrusted. Claims are checked against their source, and each proposed action against the request. Unsure cases go to a person; permissions stay in code, and every step is logged. ## Where to check ## Three places an agent needs a second look. Before a model reads external content, assess whether it contains an instruction trying to redirect the workflow. Before an answer reaches a user, check whether the cited passage supports the claim. Before a tool runs, compare its proposed action with the user’s request. These are separate questions with separate consequences. TypeSafe’s [guardrail cookbook](https://docs.typesafe.ai/cookbooks/llm_guardrails) demonstrates screening messages and using probability thresholds to route the result. We would adapt the questions to your policies and measure both missed hazards and unnecessary blocks. A model check complements [access controls](https://qquantum.ai/technology/guardrails). It cannot authorize a refund, grant database access or make untrusted content safe by declaration. Those boundaries belong in code, with a record of who requested each action. ## Checks with distinct jobs BEFORE ### Input screening Assess a message or retrieved passage for attempted instruction changes. Keep the original content labelled as untrusted, even when the classifier finds no issue. DURING ### Evidence verification Compare a proposed claim with the actual source passage. Reject missing evidence in code; ask the model about the relationship between the available text and the claim. BEFORE EXECUTION ### Action review Check whether an allowed tool action matches the request. Validate identifiers, ownership, argument types and approval status independently before executing it. ## A practical example ## Keep a support agent within its remit. Imagine an agent that drafts replies and can change delivery preferences. A customer message asks for an address update but includes unrelated instructions to export the account database. The application exposes only the permitted delivery tools; a Jev check can flag the conflicting request for review. For the reply, a separate check compares its delivery claim with the carrier record. For the address change, code verifies account ownership and asks for the required confirmation. None of these checks should silently substitute for another. This is a proposed design, not a claim that Jev catches every attack. TypeSafe publishes related examples for [classifying retrieved passages](https://docs.typesafe.ai/cookbooks/classifying_rag_passages) and [checking citations](https://docs.typesafe.ai/cookbooks/citation_check). ## Decision path PROPOSED AGENT CHECKPOINT 1. 01 Proposed action request + evidence 2. 02 Jev checks intent · support · risk 3. 03 Policy gate allow · review · block 4. 04 Permission check identity + scope 5. 05 Execute & audit approved actions only Timeouts and uncertain answers use an explicit fallback. A model’s confidence never grants permission. ## Measure both sides ## A guardrail must catch problems without stopping useful work. Build the evaluation set from representative normal traffic, known bad examples and difficult boundary cases. Report false positives and false negatives separately. An aggregate pass rate hides the difference between an overblocking system and a permissive one. Test ambiguous phrasing, conflicting evidence, provider errors and unavailable checks. Decide which operations pause for review and which can safely continue through a deterministic fallback. Track the added response time as part of the user’s complete task. TypeSafe explicitly lists adversarial inputs among the model’s [known limitations](https://docs.typesafe.ai/model-jaggedness/jev-1.13). Treat a model change as a reason to re-evaluate the policy. Our [prompt-injection guide](https://qquantum.ai/resources/prompt-injection) covers the surrounding system controls. Questions ## Questions about Jev Agent Guardrails. ### Can Jev make an agent completely safe? No. A model can misclassify a request or miss an attack. Use its decisions alongside least-privilege tools, validated arguments, approvals and monitoring. ### Can several checks share one call? Yes, when they evaluate the same available state independently. A check that needs a tool result must wait until that result exists. ### How do we choose confidence thresholds? Use held-out examples and the consequences of mistakes. Different actions need different thresholds; record review load as well as detection quality. Keep reading - [Model Build with Jev](https://qquantum.ai/technology/jev) - [Use case Model Routing](https://qquantum.ai/technology/jev/model-routing) - [Validation AI Evaluation](https://qquantum.ai/technology/ai-evals)