Avrik AIGet the models
Models NewAvrik-Lite-4BAvrik-Pro-12BAvrik-Max-31BGuard Coming soonHow it worksGet the models
Avrik Guard is coming soon

Steering, not just blocking.

Avrik Guard is the runtime security platform for AI agents. It checks every tool call, output, and handoff against your policy and a calibrated decision model, then lets the action through, corrects course, brings in a human, or stops it.

Coming SoonSee a guardrail
≤ 1 msp99 for a rules-only decision, in processDesign target
20,000+Decisions per second on one coreDesign target
≤ 5 sTo push a policy change to every live agentDesign target, p95
≤ 2 sFor a signed kill switch to reach the fleetDesign target, p95

Guardrails nobody can measure. Evals that can’t act.

Agent safety is split across tools that each do one part of the job, with three definitions of “risky” that drift apart.

Policy engines

Enforce rules reliably, but can’t judge what the user actually intended.

Guardrail hooks

Judge intent, but with hand-picked thresholds and no known error rate.

Eval platforms

Measure quality, but after the fact. They observe failures instead of preventing them.

Avrik Guard

One decision contract, written once. Enforced inline, measured in shadow mode, and calibrated from labeled outcomes.

Seven ways to respond.

Blocking is a blunt tool. Most risky moments call for something smaller: a nudge, fewer tools, or a quick human check.

Runs at every checkpoint

  • Model input
  • Model output
  • Tool call
  • Tool result
  • Trajectory step
  • Agent handoff
  • Memory read and write
  • Completion
  1. allow

    The action runs as planned.

  2. steer

    The agent gets a corrective message and tries again.

  3. restrict_tools

    Risky tools are removed for the rest of the session.

  4. require_evidence

    The agent can’t finish until it shows proof, like a passing test run.

  5. escalate

    The agent pauses for a human, then resumes with their answer.

  6. deny

    This action is refused. The agent keeps working.

  7. halt

    The run stops.

Rules first. Judgment second.

A guardrail ties a checkpoint to four stages. Deterministic policy always runs before any model is asked, and a model probability can never override a policy deny.

  1. 1

    Trajectory conditions

    Workflow rules over the whole session: what must happen first, cooldowns, and limits.

  2. 2

    Rules

    Rego or Cedar policy. Any deny ends evaluation immediately, with no model call.

  3. 3

    Checks

    Typed questions about intent and context, sent as one batched call to a decision model.

  4. 4

    Combiner

    A CEL expression with fitted thresholds turns the probabilities into one action.

kind: Contract
metadata: { name: refund-payment-guard }
spec:
  checkpoint: tool.before
  selector: { tools: [refund_payment] }
  riskClass: financial          # fails closed

  rules:
    - rego: policies/payments.rego#data.avrik.payments.decision

  checks:
    intent_aligned:
      noul: Did the user explicitly ask for a refund?

  combiner:
    allow_if: "intent_aligned >= 0.90"
    otherwise: escalate

Earned autonomy.

For each kind of action people approve today, Avrik measures whether the approval step can safely go away. Reviewers decide blind, without seeing the model’s answer, so the comparison stays honest.

  1. L0

    Human approves all

    Every action in the class waits for a person.

  2. L1

    Shadow

    Avrik decides alongside the human without acting, and the two are compared.

  3. L2

    Eligible

    The measured error rate meets your bar, with 95% confidence.

  4. L3

    Autonomous

    Avrik decides. A blind audit sample keeps measuring quality.

  5. L4

    Attested

    Autonomy is backed by signed evidence. Drift re-arms human review.

Built for the agentic threat model.

Mapped to all ten risks in the OWASP Top 10 for Agentic Applications. When a session reads untrusted content, its tool access tightens automatically.

Avrik decides what an agent may do. It is not a sandbox or a network firewall, and works alongside both.

  • Goal hijacking through indirect prompt injection
  • Tool misuse and scope creep
  • Credential reads followed by data leaving the system
  • Sensitive data in model output
  • Hidden instructions in tool descriptions
  • MCP servers that change their schema after approval
  • Look-alike tool names across MCP servers
  • Destructive shell commands and curl-pipe-to-shell
  • Poisoned agent instruction files and memory
  • Loops and runaway budgets

Runs in your agent, not in front of it.

Decisions happen in process, next to the agent. The engine is a control plane, not a proxy on every call, so a network blip never becomes an outage.

  • RuntimeAn embedded Rust core in every agent. It verifies signed policy bundles, evaluates rules, redacts sensitive data, and keeps session state.
  • SDKsOpen-source Python, TypeScript, and Go SDKs with framework adapters. Often a single line to add.
  • EngineThe control plane. It compiles and signs policy, runs the review queue and calibration, and ingests decision events.
  • ConsoleWrite guardrails, simulate them on past traffic, review escalations, and browse the ledger.
  • Proxy and hooksEnforcement for MCP servers, HTTP APIs, and coding agents like Claude Code, Codex, Cursor, and Copilot CLI, with no code change.
  • CLIValidate, test, compile, and replay guardrails in CI.

Planned framework support

  • LangChain
  • LangGraph
  • Strands Agents
  • OpenAI Agents SDK
  • Vercel AI SDK
  • Google ADK
  • CrewAI
  • Mastra
  • Pydantic AI
  • LlamaIndex
  • MCP
  • Amazon Bedrock AgentCore

Evidence your auditors can verify.

Every decision is hash-chained into signed Merkle roots. Export a signed evidence pack mapped to the frameworks you report against.

  • EU AI ActArticles 9, 12, 14, 15, 19, and 26
  • ISO/IEC 42001AI management systems
  • NIST AI RMFGovern, map, measure, and manage
  • SOC 2Control evidence for your audit

Be first to steer your agents with Avrik.

Avrik Guard is in development with a small group of design partners.

Coming SoonExplore Avrik Models