RADAR Documentation

Early beta for evaluation only.

Pre-action assessment layer for AI agents. RADAR structures reasoning before your agent acts.

RADAR provides risk intelligence, not safety assurance. It assesses the action description supplied by the developer or agent — it does not verify the real-world action that is executed. A PROCEED verdict means “not held by this assessment” — it is not authorisation, approval, certification, legal advice, or safety validation. RADAR can produce a PROCEED verdict for actions that later prove harmful, incorrect, unethical, or non-compliant. Liability remains with the developer, operator, or user. If an external LLM provider is configured, action text leaves the local machine and is sent to that provider under your own account and policies. This is a beta release — not recommended for enterprise or production use without independent legal and compliance review.

When RADAR adds value

RADAR is not a replacement for VS Code’s permission prompts or Claude Code’s built-in allow/deny system. Those control whether an action is permitted on your machine. RADAR answers a different question: should this action happen at all, given the risk?

RADAR is not a classifier. It does not reduce decisions to allow or block — it expands them into structured trade-offs. RADAR surfaces multiple viable risk responses (avoid, mitigate, transfer, accept) rather than collapsing decisions into a single verdict.

RADAR adds value when:

• Your agent runs unsupervised — no permission prompt will fire. RADAR is the governance layer between intent and action when there is no human in the loop.
• The action affects other people — sending to 50,000 users, deleting customer records, processing payments. VS Code permissions don’t cover these.
• You need an audit trail — RADAR creates a permanent record of every assessment. VS Code’s allow/deny creates none.
• You’re deploying agents in an organisation — consistent governance across multiple agents and operators.

RADAR adds less value when:

• You are a developer watching every action in your IDE
• VS Code’s permission prompts already cover the actions you care about
• All your agent’s actions are reversible and low-stakes

The MCP integration lets you test your RADAR configuration interactively in Claude Code, Cursor, or any MCP-compatible AI assistant before deploying agents to production.

Integration patterns

Installation

Prerequisites

• Node.js 18 or higher — nodejs.org
• npm (included with Node.js)

Windows users: use Command Prompt or PowerShell with execution policy set to RemoteSigned. If you see “running scripts is disabled”, run this in PowerShell as Administrator:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

npm install @essentianlabs/radar-lite

You may see deprecation warnings during install — these are from upstream dependencies and do not affect functionality.

RADAR runs as a local package in your Node.js project. T1 and T2 assessment logic runs in your application environment. If you configure an external LLM provider, action text is sent to that provider using your account and API key.

MCP Server: Use RADAR from Claude Code, Cursor, or any MCP-compatible AI assistant:
npm install @essentianlabs/radar-mcp

OpenClaw: RADAR integration for OpenClaw agents:
npm install @essentianlabs/openclaw-radar

Configuration

Call radar.configure() once at startup. Without any keys, Vela Lite falls back to the rules engine only. With an LLM key, both T1 and T2 call the LLM — T1 uses a fast model, T2 uses a reasoning model. An API key additionally unlocks Vela server-side for T3/T4.

import { radar } from '@essentianlabs/radar-lite';

radar.configure({
  llmProvider: 'anthropic',          // T1 scorer (haiku / gpt-4o-mini / gemini-flash)
  llmKey:      'sk-ant-xxxx',        // required — Vela Lite needs this to reason
  t2Provider:  'openai',              // T2 reviewer — optional, different provider recommended
  t2Key:       'sk-xxxx',             // your key for the T2 provider (optional)
  apiKey:      'rdr_live_xxxx',       // optional — unlocks Vela server-side (T3/T4)
  activities: {
    email_single:  'balanced',        // permissive | balanced | conservative
    email_bulk:    'conservative',
    financial:     'conservative',
  },
  webhookUrl: 'https://your-app.com/radar-escalation'  // T4 escalation target (paid)
});

Configuration fields

LLM model selection

T1 uses a fast model for quick scoring. T2 uses a reasoning model for deeper review. Model selection is handled automatically based on your configured provider.

Without a key, both T1 and T2 fall back to the rules engine only — no LLM calls, no cost.

Segregation of duties

Using a different provider for T2 adds an independent check. This is why t2Provider and t2Key exist as separate fields. Optional but recommended for high-stakes activity types.

Cost

Every assess() call with a key = one LLM call. T1 uses fast model pricing (lowest tier). T2 uses reasoning model pricing (higher tier, but T2 fires less often — only above the T2 threshold). Most calls resolve at T1, so the majority of your spend is at fast-model rates.

Your first assessment

Wrap any output action with radar.assess(). It returns a verdict telling your agent whether to proceed.

const result = await radar.assess(
  'Send price increase email to 50,000 users',
  'email_bulk'
);

console.log(result);
// {
//   "call_id": "ra_xxxxxxxxxxxx",
//   "verdict": "HOLD",
//   "majority": "HOLD",
//   "models_consulted": ["claude-sonnet-4-6", "gpt-4o", "gemini-2.0-pro"],
//   "vela_consulted": true,
//   "suggestion": {
//     "tldr": {
//       "verdict": "AVOID",
//       "primary_risk": "Irreversible bulk communication without staged rollout",
//       "action": "Stage to 5% cohort first, monitor 2 hours"
//     },
//     "options": {
//       "avoid": "Do not send — requires comms review",
//       "mitigate": "Stage to 5% cohort first, monitor 2 hours",
//       "transfer": "Route through compliance vendor pre-send",
//       "accept": "Send as-is, document business justification"
//     }
//   },
//   "tier": 3,
//   "risk_score": 14,
//   "response_time_ms": 2800
// }

Response fields (server API)

The four decision options are: avoid, mitigate, transfer, and accept. Your agent can follow the tldr.action recommendation or apply its own logic.

The npm package (@essentianlabs/radar-lite) returns a different response shape for local T1/T2 assessment. See the package README for Lite response fields.

POST /radar/assess

Submit an action for server-side risk assessment. Returns a tier assignment, risk score, and suggestions. Used for T3/T4 when the local SDK escalates to the server panel.

Request

Example request

curl -X POST https://radar.essentianlabs.com/radar/assess \
  -H "Authorization: Bearer rdr_live_xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "Delete all user records older than 2 years",
    "activity_type": "data_delete_bulk",
    "agent_id": "data-agent"
  }'

Example response

{
  "call_id": "ra_abc123def456",
  "verdict": "HOLD",
  "majority": "HOLD",
  "models_consulted": ["claude-sonnet-4-6", "gpt-4o", "gemini-2.0-pro"],
  "vela_consulted": true,
  "suggestion": {
    "tldr": {
      "verdict": "AVOID",
      "primary_risk": "Irreversible bulk deletion without compliance review",
      "action": "Route to DBA for manual review before execution"
    },
    "options": {
      "avoid": "Do not delete — requires compliance sign-off",
      "mitigate": "Archive records instead; purge after 30-day review",
      "transfer": "Route to database administrator for manual review",
      "accept": "Proceed with deletion, document decision and rationale"
    }
  },
  "tier": 4,
  "risk_score": 21,
  "response_time_ms": 3200
}

Error codes

POST /radar/register

Register for a free API key. No credit card required. Enables enhanced suggestions immediately.

Request

Example

curl -X POST https://radar.essentianlabs.com/radar/register \
  -H "Content-Type: application/json" \
  -d '{ "email": "dev@example.com" }'

{
  "api_key": "rdr_live_abc123def456",
  "plan": "free",
  "message": "API key created. Store it securely — it won't be shown again."
}

POST /radar/config

Update your activity slider positions server-side. Accepts permissive, balanced, or conservative. Synced to the local SDK on next assessment.

Request

{
  "activities": {
    "email_bulk": "conservative",
    "financial": "conservative",
    "publish": "balanced"
  }
}

POST /radar/webhook

Register or update your T4 escalation webhook URL. When an action reaches T4, RADAR sends a POST to this URL with the escalation payload.

Webhook payload (sent to your URL)

{
  "escalation_id": "esc_abc123",
  "tier": "T4",
  "risk_score": 22,
  "activity_type": "financial",
  "suggestion": { /* same shape as /assess response */ },
  "timestamp": "2026-03-26T14:30:00Z"
}

GET /radar/history

Returns the last 100 scoring metadata records. No action content is stored or returned — only anonymised signals.

Example response

{
  "records": [
    {
      "id": "rec_001",
      "tier": "T2",
      "risk_score": 7,
      "activity_type": "email_single",
      "verdict": "mitigate",
      "timestamp": "2026-03-26T10:15:00Z"
    }
  ],
  "total": 47
}

GET /radar/health

Health check endpoint. Returns server status.

{
  "status": "ok",
  "version": "1.0.0"
}

Vela and Vela Lite

Vela Lite ships inside the @essentianlabs/radar-lite npm package. She runs locally using your own LLM keys. Without any key, she falls back to rules engine only.

Vela Essentian™ is the paid tier. She handles T3 and T4 on EssentianLabs servers.

Free — Vela Lite. Local. Private. Good.
Paid — Vela Essentian. The more your agents use RADAR, the more precisely Vela reasons about your specific deployment context.

Action text is never retained at any tier. Vela Lite is fully stateless — each evaluation starts fresh. Vela Essentian™ retains assessment metadata (patterns, outcomes, calibration data) to improve precision over time. The output spectrum runs from a single line at T1 to a boardroom-ready briefing package at T4. Same interface. Same function call.

Tier logic

Before any tier assessment runs, paid tier deployments check the agent's mandate. If the agent has no active mandate or the action falls outside its mandate scope, RADAR returns DENY immediately — no tier assigned, no LLM call. This is the eRM (Essentian Risk Management) authorisation layer.

The four-tier assessment runs only when the mandate check passes.

Every action is then assessed and assigned a tier. T1 and T2 run locally using your LLM key. T3 and T4 escalate to Vela on the EssentianLabs server.

Agent Mandates are paid tier only. Free tier deployments skip the mandate check and proceed directly to T1 scoring. See Agent Mandates documentation for details.

What Vela produces at each tier

T1 — one line

VELA LITE (T1) | PROCEED | Standard data read within scope | data_read | score 2

T2 — TL;DR

VELA LITE (T2) | email | score 8

HOLD — staged rollout before full send.

→ AVOID:     Block send, route to communications review
→ MITIGATE:  Stage to 5% cohort first, monitor 2 hours (recommended)
→ TRANSFER:  Route through compliance vendor pre-send
→ ACCEPT:    Send as-is, document business justification

— Vela Lite · EssentianLabs

T3 — full assessment

Primary risk driver. Secondary factors. Proportionality trace. Four fully argued options with implementation detail. Vela's closing note.

T4 — full assessment + human briefing package

Everything T3 produces, plus:

• Relevant precedents from your risk register
• Vela's explicit recommendation to the human
• Four options presented as a decision to sign off
• Decision recorded with the human's name attached

LLM providers and model selection

T1 uses a fast model for quick scoring. T2 uses a reasoning model for deeper review. Model selection is handled automatically based on your configured provider. Anthropic, OpenAI, and Google are supported.

Without a key, both T1 and T2 fall back to the rules engine only — no LLM calls, no cost.

With a key, every assess() call = one LLM call. T1 uses fast-model pricing. T2 uses reasoning-model pricing but fires less often, so most calls are T1-priced.

Segregation of duties

Using a different provider for T2 adds an independent check. Set t2Provider and t2Key to a different provider. Optional but recommended for high-stakes activity types.

Slider configuration

Each activity type has a slider with three positions: Permissive, Balanced, and Conservative. The slider controls how aggressively actions escalate to higher tiers.

At conservative settings, more actions escalate to higher tiers. At permissive settings, only the riskiest actions leave T1.

Policy upload

Each activity type can have an uploaded policy that Vela checks against during assessment. When a policy is uploaded for an activity, RADAR adds an additional LLM call to every assessment of that activity type — including T1 actions that would otherwise be cheap.

Cost implication. Without a policy, a T1 assessment of activity X is one LLM call (the oneliner). With a policy uploaded for X, every T1 assessment of X becomes two LLM calls (oneliner + policy compliance check). This is the operator's choice when uploading a policy.

The dashboard policy editor (Settings → expand any activity → Policy panel) shows the estimated added token count per assessment before you save. Approximate heuristic: 4 chars ≈ 1 token; multiply by your provider's input-token rate to estimate the per-assessment delta.

Free tier: 2,000 character cap per activity policy, one policy per activity. Paid tier: hosted policy library, multi-policy per activity, no practical cap.

Uploading a policy is opt-in. To remove the added LLM call, delete or disable the policy from the dashboard.

Local risk register

RADAR maintains a local SQLite database at .radar/register.db in your project directory. This register:

• Stores action hashes (SHA-256), never action text
• Feeds context into future assessments (repeat detection, pattern analysis)
• Is entirely under your control — delete it, back it up, or inspect it anytime
• Never synced to any server

What RADAR assesses

RADAR assesses actions — what your agent intends to do — not outputs — what your agent has produced.

An action is an intended operation:

✓ “Send email to 50,000 users”
✓ “Delete all records older than 2 years”
✓ “Execute payment of £500 to vendor”

An output is the content produced by that operation:

✗ The email body text
✗ The list of records to delete
✗ The payment confirmation message

Pass the intended operation as the action string. If you pass content instead of an action, Vela will flag it and return HOLD.

What RADAR does not do

RADAR does not:

• Verify that the agent actually executes the action as described
• Enforce compliance with any regulatory framework
• Replace legal review or professional advice
• Guarantee safety, correctness, or ethical outcomes
• Verify the truthfulness of the action description submitted to it

RADAR structures reasoning about intended actions. It is a decision-support layer, not a permission system or compliance engine.

RADAR outputs can be misused as justification for decisions rather than inputs to them. A verdict is an assessment, not a defence.

Runtime meaning of the verdict

PROCEED — not held by the current assessment path. The action was evaluated against the configured rules, thresholds, and (if available) LLM reasoning. No reason to stop was identified. This is not authorisation, approval, or a guarantee of safety. A PROCEED verdict does not imply that alternative, lower-risk options do not exist.

HOLD — requires review or intervention according to the current configuration and policy. The action was flagged by risk scoring, LLM reasoning, or human-review rules.

DENY — blocked by configured policy. The action matched a rule that prohibits autonomous execution, or (paid tier) violated the agent's mandate scope. DENY is a hard stop. Override requires explicit documented decision via override_deny.

Neither PROCEED, HOLD, nor DENY is a substitute for human accountability. All three are assessment outputs, not permission grants.

Execution policy — separate from RADAR

RADAR governs risk assessment. Your agent governs execution permissions. These are separate concerns.

RADAR tells you: is this action risky?
Your execution policy tells your agent: am I permitted to take this action autonomously?

A well-governed agent has both layers:

1. RADAR — assess the risk before acting
2. Execution policy — define what the agent may do autonomously based on the verdict

Example: RADAR returns PROCEED on “restart nginx”. Your execution policy says nginx restarts always require human approval. The agent escalates — even though RADAR cleared it.

This is intentional. RADAR is risk intelligence, not a permission system. Execution permissions are your agent's responsibility.

The exception is Agent Mandates (paid tier), which provide scoped, revocable permission infrastructure for agents. Mandates define what each agent is authorised to do — not what level of risk it can accept. Mandate enforcement is deterministic (DENY for out-of-scope actions), while RADAR risk assessment remains advisory (PROCEED or HOLD on permitted actions).

Agent Mandates — paid tier

Every regulated environment will eventually need to answer three questions about any AI agent action:

RADAR's Agent Mandate system answers all three.

A mandate is a scoped, time-limited authorisation issued to an agent by a named human principal. It defines which actions the agent is permitted to take, when the authorisation expires, and who can revoke it.

When an agent submits an action for assessment, RADAR checks the mandate first:

• No active mandate → DENY (no_mandate)
• Action outside mandate scope → DENY (out_of_scope)
• Action within mandate scope → proceed to assessment

Every call record includes the mandate ID, the principal who issued it, and whether the action was in scope. This is the audit trail that holds up when something goes wrong.

Agent Mandates are available on the paid tier. The free tier (Vela Lite) uses activity sliders and trigger policy for action-level control — sufficient for development and testing. Mandates are designed for production deployments in regulated environments where accountability must be traceable to a named human authority.

Register interest →

Trusted inputs and prompt-injection boundary

RADAR does not validate the accuracy of the action description. Incorrect or incomplete inputs will produce incorrect assessments. In agent pipelines, upstream prompt-injection and context-integrity controls are still required. RADAR Lite is not a standalone prompt-injection defence — it assesses what it receives, not how that input was constructed.

Scope hygiene — advisory only

T3/T4 server-side review responses include a scopeHygiene field. It asks the reviewing LLM whether the action description, activity_type, and trigger reason are mutually consistent — for example, whether an action described as “delete one record” was correctly classified as data_delete_single rather than data_delete_bulk.

Scope hygiene checks are advisory, not authoritative. The check is a best-effort prompt instruction; different LLM providers attend to it differently. In internal validation, Anthropic models flagged scope mismatches more reliably than OpenAI models, which often defaulted to “no issues.”

Treat scopeHygiene as a useful signal when it fires, but do not build workflows that assume scopeHygiene.issuesDetected === false means “clean.” Absence of detection is not certainty of absence. Use this field to surface concerns, not to confirm safety.

Predictable assessment and inspectability

RADAR's local assessment is predictable — the same input produces the same verdict. This is by design: it makes outcomes inspectable and auditable, which matters when something goes wrong.

It also means a sufficiently informed user can predict the verdict for any given input. Do not treat RADAR as a security control or anti-abuse mechanism. An agent or user who wants a particular verdict can describe the action in a way that produces it. RADAR assesses what it is told, not what is true.

For adversarial or high-stakes scenarios, combine RADAR with independent review — human approval at decision points, separate validation of the action description, and orchestration-layer enforcement that does not rely on the agent itself respecting the verdict.

Disabling RADAR

You can disable RADAR assessment by setting RADAR_ENABLED=false in your .radar/.env file, or via the dashboard Settings tab.

When disabled, radar.assess() returns PROCEED immediately without calling Vela. All bypass events are recorded in the local risk register regardless of this setting.

Note: disabling RADAR does not disable logging. Every bypassed call is recorded with a timestamp, activity type, and bypass flag. This record exists for your own audit trail.

Privacy and data flow

Rules engine only (no LLM key configured): All scoring runs locally. No action text leaves your machine. No external calls.

With LLM key configured (T1/T2): Action text and relevant context are sent to the configured LLM provider (Anthropic, OpenAI, or Google) using your account and API key. RADAR Lite does not send action text to EssentianLabs servers for T1/T2 assessment, but external provider traffic occurs depending on your configuration.

Vela Essentian (T3/T4, paid): Action text is transmitted to the EssentianLabs server for deliberation. It is processed in memory and immediately discarded — never written to disk, never stored in any database, never used for training.

What we store (all plans): anonymised scoring metadata only.

Nothing in this schema can identify your users or reveal what your agent was doing.

Pricing

Free — Vela Lite

T1 and T2 assessment logic runs in your application. Rules engine is fully local. If you configure an LLM provider, action text is sent to that provider under your account.

Vela Lite assesses each action independently — no learning, no memory between sessions. Every assessment starts fresh.

— No assessment memory between sessions
— Each agent assessed independently
— Fully local — no data sent to EssentianLabs

npm install @essentianlabs/radar-lite

Paid — Vela Essentian™

T3 and T4 run on EssentianLabs servers. The more your agents use RADAR, the more precisely Vela reasons about your specific deployment context.

✓ Agent Mandates (eRM) — scoped, revocable, auditable agent authorisation
✓ Multi-model deliberation at T3
✓ Human escalation at T4 with named accountability
✓ Vela improves with use — assessments get more accurate over time for your action types

Early access — hello@essentianlabs.com

Enterprise — Vela Essentian™ + Auditor

Named accountability at T4. Regulatory audit trail. Auditor agent for trend detection and compliance reporting.

Contact us — hello@essentianlabs.com

Licensing

The RADAR client packages — radar-lite, radar-mcp, openclaw-radar — are MIT licensed and free to use. The hosted Vela Essentian™ service and supporting infrastructure are proprietary and operated by EssentianLabs.

RADAR provides risk intelligence to inform agent governance decisions. It is not a compliance certification, a legal opinion, or a guarantee of safe operation. EssentianLabs is not liable for actions taken by agents operating under RADAR assessment. The developer is responsible for the accuracy of action descriptions submitted and the consequences of actions executed. Beta Terms of Use