Docs · Integration

Integration Guide. Wire VARUX into your stack.

Guides for enterprise agents, automation systems, and LLM platforms with best practices. Use this guide to decide where VARUX lives in your architecture and how to roll it out safely.

Enterprise agents
Automation & workflows
LLM platforms
Scenarios

Where VARUX sits in your architecture

Three common integration patterns map to most real-world setups. Pick the one closest to your environment, then adapt it.

Pattern · Enterprise agents

Embedded client in the orchestrator

Your internal agent platform (orchestrator) calls VARUX directly whenever an agent wants to use a tool or touch memory.

  • Use the SDK inside the orchestrator process.
  • Decorate tool calls with evaluate() checks.
  • Send telemetry events for audits and debugging.
Pattern · Automation systems

Security gateway in front of tools

A lightweight service sits between agents and critical tools (payments, ERP, ticketing) and consults VARUX before executing.

  • Expose an internal HTTP/GRPC gateway.
  • Gateway talks to VARUX and enforces decisions.
  • Existing tools remain unchanged behind the gateway.
Pattern · LLM platforms

Policy layer around tools & vector stores

VARUX policies are bound to tools and memory scopes inside your LLM platform, giving you consistent behavior across agents and use cases.

  • Register tools and vector scopes via API.
  • Resolve policies per tenant or workspace.
  • Log denied calls for later review.
Architecture

Rollout strategy & guardrails

Introduce VARUX in stages: visibility first, then soft enforcement, then hard blocks. That keeps agents online while you raise security.

Start by mirroring traffic and recording telemetry without blocking anything. Once you trust the policies, enable soft enforcement and only log violations. Finally, turn on hard blocks for high-risk actions.

This three-step rollout works across enterprise agents, automation systems and LLM platforms without breaking existing workflows.

Observe first Soft enforce Hard enforce Per-tenant controls
Stage What you do Environment
1 · Visibility Integrate SDK/gateway, send telemetry only, no blocking. dev / staging
2 · Soft enforcement Policies in "monitor" mode, violations are logged but allowed. staging / limited prod
3 · Hard enforcement Enable "block" on high-risk policies, keep fallbacks for critical paths. production
Best practices

Checklist before enabling blocks

  • Tag agents with tenant, environment and risk level.
  • Start with read-only policies for vector stores and tools.
  • Roll out per-team or per-tenant instead of a big-bang switch.
  • Export telemetry to your SIEM/observability stack.
  • Keep a "break glass" path for critical operations.
Platforms

Enterprise, automation, LLM

A quick summary of what to pay attention to for each type of deployment so you don't repeat the same mistakes in three different stacks.

Enterprise agents

Internal copilots & assistants

Focus on identity and tenant boundaries. Every agent call should carry a stable user identifier and tenant id into VARUX.

  • Bind policies to roles and groups, not individual users.
  • Guard file systems, ticketing and internal APIs first.
  • Use audit logs to review denied actions with security teams.
Automation systems

Workflows & background jobs

Automations tend to run unattended. Treat them like privileged service accounts with strict policies and telemetry.

  • Require explicit policies for payments, HR and finance tools.
  • Throttle high-volume workflows via rate limits in VARUX.
  • Alert when new tools are used without an attached policy.
LLM platforms

Hosted or self-managed platforms

Vector stores and tools are shared across many agents and tenants. Policies should be aware of both.

  • Model vector scopes as first-class resources in VARUX.
  • Enforce per-tenant isolation at the policy layer.
  • Surface policy decisions back into your platform logs.