Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.visiqlabs.com/llms.txt

Use this file to discover all available pages before exploring further.

​
How Rules Work

Rules define what actions your agents are permitted to perform. Every outbound request intercepted by the SDK is evaluated against your rule set. Rules are compiled into an optimized bundle that SDKs download and cache locally — evaluation happens in-process with no network round-trip on the hot path. Each rule targets a specific application or API (resource_type), matches based on conditions (action, agent ID, request context), and applies an effect: permit the request, deny it, or route it to a human for approval.

​
Rule Structure

A rule has the following fields:
FieldTypeDescription
namestringHuman-readable name for the rule
descriptionstringOptional longer description
effectallow | deny | hitlWhat happens when this rule matches
resource_typestringThe target app this rule applies to (e.g. stripe.com, github.com, or * for all)
conditionsRuleCondition[]List of field/operator/value conditions that must all match
prioritynumberRules with higher priority are evaluated first. Default: 0
enabledbooleanWhether the rule is active. Disabled rules are excluded from the bundle

​
Example Rule (JSON)

{
  "name": "Allow Stripe read operations",
  "description": "Permit GET requests to Stripe — billing agent reads only",
  "effect": "allow",
  "resource_type": "stripe.com",
  "conditions": [
    { "field": "action", "operator": "equals", "value": "GET" },
    { "field": "agent_id", "operator": "in", "value": ["billing-agent", "reporting-agent"] }
  ],
  "priority": 10,
  "enabled": true
}

​
Condition Operators

Conditions match against fields extracted from the intercepted request: agent_id, target_app, action (HTTP method or method + path), and any additional context your agent passes.
OperatorDescriptionExample
equalsExact string matchaction equals "POST"
inValue appears in a listagent_id in ["billing-agent", "reporting-agent"]
not_equalsValue does not equal the targetaction not_equals "DELETE"
not_inValue does not appear in a listagent_id not_in ["untrusted-agent"]
A rule matches only when all of its conditions match. A rule with zero conditions matches every request for its resource_type.
Undefined fields fail-closed. If a condition references a field not present in the request context, the condition does not match — undefined is never treated as a match target.

​
Natural Language Rules

You can describe rules in plain English. ALLOW compiles them to policy using AI (powered by the POST /allow/rules/compile endpoint). No Rego expertise required. Example prompt: “Allow my billing agent to make GET requests to Stripe but block all write operations including POST, PUT, PATCH, and DELETE” Compiled result: 
{
  "name": "Billing agent — Stripe read-only",
  "effect": "allow",
  "resource_type": "stripe.com",
  "conditions": [
    { "field": "agent_id", "operator": "equals", "value": "billing-agent" },
    { "field": "action", "operator": "in", "value": ["GET", "HEAD"] }
  ],
  "priority": 10
}
The compiler reads your existing rules for context before generating new ones, ensuring the new rule fits coherently into your policy set. It validates the Rego syntax and saves the rule directly to the database if the compile succeeds.

​
Rule Evaluation Flow

When the SDK intercepts an outbound request:
  1. The SDK extracts target_app (the hostname) and action (the HTTP method, or method + path) from the request URL and headers.
  2. The ALLOW rule engine iterates through the cached bundle in priority order (highest priority first).
  3. The first rule whose resource_type matches and whose all conditions match wins.
  4. The winning rule’s effect is applied: allow → permit, deny → block, hitl → pause for human approval.
  5. If no rule matches, the request is an uncovered scenario (see HITL for how these are handled).
No matching rule defaults to deny in enforce mode. An empty rule set blocks every request. Start with audit mode to observe your agent’s behavior before writing rules.

​
Rule Sync

The SDK periodically fetches the latest compiled rule bundle from GET /allow/rules/bundle. The default sync interval is 30 seconds, configurable via syncIntervalMs or ALLOW_SYNC_INTERVAL_MS. Sync uses ETag / If-None-Match for efficiency — if the bundle has not changed since the last fetch, the server returns 304 Not Modified and no data is transferred. The bundle version field is a SHA-256 hash of the serialized rules array, so it changes exactly when rules change. The SDK loads an initial rule bundle on startup. If the initial fetch fails (transient server issue, no connectivity), the SDK falls back to server-side evaluation via POST /allow/evaluate until a bundle is successfully loaded on the next sync cycle.

​
Managing Rules

Rules can be created and managed via:
  • Dashboard: Navigate to Rules in the ALLOW dashboard. Use the Create Rule button for manual entry or the Compile from description input for natural language.
  • REST API: Use the Rules endpoints documented in the API Reference. Useful for programmatic rule management, CI/CD pipelines, and bulk imports.

​
Rule Priority Guidelines

Priority rangeSuggested use
100+Override rules — specific denies that should always win
10–99Normal allow rules for known-good patterns
1–9Broad catch-all rules
0Default / lowest precedence