How Rivaro Works

Rivaro is the governance control plane for AI agents. It sits at the boundary between your agents and the services they interact with -- LLM providers, external APIs, databases, tools -- and enforces policy on every interaction.

Rivaro does not deploy, run, or manage agents. Infrastructure teams, platform teams, and developers decide which agents to deploy and how. Rivaro governs what happens when those agents run.

What Rivaro Is

• A governance control plane for AI agents across any runtime, provider, or framework
• A system of record for the agent estate: what agents exist, what they're doing, what's healthy, what's drifting
• An inline enforcement layer that makes ALLOW / BLOCK / DEFER decisions before actions execute
• A cryptographic evidence layer that signs every enforcement decision with Ed25519 receipts

What Rivaro Is Not

Three things explicitly out of scope. Infrastructure teams, platform teams, and developers own these decisions:

• Not an agent runtime or orchestration platform. Rivaro does not deploy, schedule, or manage agent lifecycles. Your runtime providers (Bedrock AgentCore, Microsoft Foundry, Vertex Agent Builder, LangChain, CrewAI, homegrown frameworks) do that.
• Not an agent marketplace or procurement layer. Rivaro does not sell, distribute, or recommend agents.
• Not an agent deployment, versioning, or rollback system. Rivaro does not decide which version of an agent runs, when it's promoted between environments, or how it's rolled back. Your existing CI/CD and platform tooling owns that.

Rivaro sits at the boundary and governs what happens when whatever your team deployed actually runs.

It is also explicitly not a prompt guardrails library. SDK-level guardrails protect one application's prompt layer. Rivaro governs the entire agent estate at the network layer, across all applications, all frameworks, and all tool calls.

Two Enforcement Surfaces

Rivaro governs agents through two complementary surfaces. Both share the same policy engine, the same detection pipeline, and the same audit ledger.

Surface 1: LLM Gateway

Every call your agent makes to an LLM provider passes through the Rivaro Gateway. The gateway scans requests and responses for policy violations, applies enforcement decisions, and forwards traffic to the provider transparently.

Your Agent  →  Rivaro Gateway  →  LLM Provider (OpenAI, Anthropic, Bedrock, etc.)
                     ↓
              Detection Engine
              Policy Engine
              Audit Ledger

What it governs:

• Ingress: scans prompts for injection attacks, PII, credentials, data exfiltration attempts
• Egress: scans responses for sensitive data leakage, toxic content, unauthorized information disclosure
• Applies policy actions: ALLOW, LOG, REDACT, BLOCK, QUARANTINE, STEP_UP

Integration options:

• Direct gateway — change your SDK's base_url to point at Rivaro, add the X-Detection-Key header. No code changes beyond that.
• Observation sidecar (optional) — a thin local proxy you run alongside the agent when you cannot change base_url. Forwards traffic to the real provider and reports observations to Rivaro out-of-band. Useful for vendored SDKs, third-party agents, or appliances. Detection runs in Rivaro from the observed traffic.

Supported providers: OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, AWS SageMaker, Ollama, Slack bots, and any OpenAI-compatible API.

Surface 2: Agent Enforcement Sidecar

When agents call external tools -- APIs, databases, payment processors, messaging services -- the enforcement sidecar intercepts the outbound HTTP call and enforces policy before the tool executes.

Your Agent  →  Enforcement Sidecar (HTTP_PROXY)  →  Tool / API / Service
                       ↓
                 Pre-execution check
                 Policy evaluation
                 ALLOW / BLOCK / DEFER
                       ↓
                 Post-execution verification

What it governs:

• Pre-execution: checks whether the agent is authorized to call this tool, with these parameters, in this context
• Context-aware policy: enforces rules like "block refunds where the acting customer differs from the order's owning customer"
• Inline tool-call hold: high-risk actions pause and wait for human approval before execution; the agent's tool-call returns when (and if) the approval clears
• Post-execution: verifies that the tool's response matches the expected outcome

Integration: Set one environment variable (HTTP_PROXY=http://localhost:9090). No code changes to the agent.

Key capability -- cross-tool context: Rivaro evaluates a tool call against what the agent has already done in the same session, not just the call in front of it. That makes it possible to enforce rules like "the refund must belong to the customer whose order this agent actually looked up" — a class of control that cannot be expressed at the prompt layer, where each call is seen in isolation.

The two sidecars at a glance

Sidecar	Purpose	Where it sits
Observation sidecar	Capture LLM traffic when base_url can't be changed	Between SDK and provider
Enforcement sidecar	Hold-and-evaluate tool calls before execution	HTTP_PROXY for the agent process

Both are optional. Direct gateway integration covers most agents; the sidecars are there for the cases where you need them.

Vendor-Neutral by Architecture

Most cloud-provider control planes only govern agents inside their own ecosystem. If your agents run across multiple providers, frameworks, or homegrown stacks -- the reality for most mid-market and enterprise organizations -- each of those control planes sees only a fraction of the estate.

Rivaro governs all agents through one gateway, regardless of which provider, framework, or runtime deployed them. One policy engine, one dashboard, one audit trail.

Coverage via Integration

Rivaro is the governance layer above the runtimes -- it does not duplicate what the runtimes already do well. To give you a complete view of the agent estate, Rivaro reads from the agent and tool registries that already exist -- cloud provider agent registries, MCP server registries, and discovery scans across your infrastructure.

Each runtime remains the source of truth for its own agents. Rivaro is the source of truth for what those agents actually did when they ran.

Framework and Protocol Coverage

Rivaro governs any agent that makes HTTP calls to an AI provider or external tool. That's how the framework-agnostic claim is true in practice:

Layer	Coverage
AI provider SDKs	OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, Ollama, and any OpenAI-compatible API
Agent frameworks	LangChain, CrewAI, AutoGen, Vercel AI SDK, Semantic Kernel, raw SDK usage
Protocols	MCP (Model Context Protocol), emerging A2A (Agent-to-Agent), arbitrary outbound HTTP
Runtimes	Anywhere an agent runs -- containers, serverless, VMs, on-prem

MCP specifically: MCP tool invocations can be governed at two layers. At the HTTP layer, the agent sidecar intercepts outbound tool calls like any other agent action. At the MCP layer, Rivaro can sit between the MCP client and the MCP server, intercepting inbound MCP calls directly. Either way, every tool call passes through the same policy engine and audit ledger. If you are evaluating Rivaro against MCP-only governance tools, the relevant fact is that Rivaro covers MCP and everything else through the same control plane.

What Rivaro cannot govern: Agents with closed execution loops -- where the LLM call and the resulting action both happen entirely inside a vendor's runtime with no outbound HTTP. Examples: GitHub Copilot, Microsoft 365 Copilot, embedded copilots. Rivaro governs traffic that crosses a network boundary. If there's no boundary, there's nothing to intercept. For visibility into these tools, see Discovery & Shadow AI.

AARM Alignment

Rivaro is designed around the Autonomous Action Runtime Management (AARM) specification — a Cloud Security Alliance standard for governing autonomous AI agent actions at runtime — and is listed in the AARM Builder Registry.

Every enforcement decision produces a cryptographically signed action receipt as part of Rivaro's evidence layer.

Each receipt contains:

• What agent took the action
• What action was attempted
• What policy was evaluated
• What decision was made (ALLOW, BLOCK, DEFER, etc.)
• A timestamp and integrity hash linking to the previous receipt

Receipts are signed with Ed25519 keys and can be verified in the browser using @noble/ed25519. They are not logs -- they are cryptographic proof of what happened, verifiable offline by auditors and examiners.

Rivaro's implementation is built against the AARM requirement areas. Formal conformance follows the AARM review process.

Detection Engine

Rivaro's detection pipeline is organized in two layers: risk domains (the governance categories that policy attaches to) and detectors (the code that finds violations). There are 8 risk domains, 17 risk categories, and 12+ specialized detectors covering PII, PHI, financial data, credentials, prompt injection, tool misuse, behavioral anomalies, and more.

Each detector uses a multi-strategy approach: pattern matching (fast, deterministic), ML classification, and LLM-as-judge (for nuanced cases). For the full reference, see Understanding Detections.

Policy and Enforcement

When a detection fires or an enforcement check runs, Rivaro applies a policy action: ALLOW, LOG, REDACT, BLOCK, DEFER (human approval), STEP_UP (additional auth), QUARANTINE, or RISK_ADAPTIVE (action escalates through configured risk bands).

Policy actions can be configured per detector, per risk category, or via risk-adaptive enforcement families that tie actions to cumulative risk scores. Budget limits are enforced as a gate in the enforcement chain. For configuration details, see Enforcement & Policies and Budget & Cost Management.

After actions execute, Rivaro tracks outcomes — verifying agent claims against actual tool results, tracking delegation chains across multi-agent systems, and grouping impacts by affected system. See Outcomes & Traceability.

Deployment Models

Model	Description	Best For
Run locally	Full Rivaro stack on your machine with Docker. No signup.	Evaluation, hands-on testing, POCs
Rivaro Cloud	Rivaro-managed infrastructure. Sign up, get a gateway URL.	Teams and workspaces, ongoing use
Self-hosted (VPC)	Full deployment in your infrastructure. You control the data plane.	Regulated industries, data residency, air-gapped environments

Sync vs. Async

Enforcement checks, detection, and policy evaluation are inline (sync) -- they happen before the action executes. Dashboard logging, analytics, audit writes, and receipt signing are async and add no latency to the request path.

Latency

Rivaro adds overhead for ingress detection, policy evaluation, and session management before forwarding the request to the LLM provider. On hosted Rivaro (Rivaro Cloud), expect ~150-200ms of gateway overhead. On a local install, overhead is significantly lower because all services are on the same machine with no network hops.

In both cases, the LLM provider's response time (typically 500ms-2s+) dominates total request duration.

Streaming: For streaming responses — which is most real agent usage — there are three enforcement modes you can pick per AppContext:

Mode	Behavior	When to use
Observe (default)	Tokens stream straight through; egress detection runs on the buffered response after the stream closes. User-perceived latency is ingress overhead + LLM time-to-first-token.	Production agent UX where token streaming is required
Inline redaction	Detect-and-rewrite on the live stream — chunks containing sensitive matches are redacted before they reach the agent. Adds a small per-chunk overhead.	Customer-facing chatbots, PHI / PII egress without delaying the experience
Full buffer	Hold the entire response until detection finishes, then deliver or block. No tokens are exposed if the response will be blocked.	Highly regulated egress where you cannot leak even partial sensitive content

Modes are configured per AppContext in Settings > Enforcement.

Sidecar: Pre-execution enforcement checks on tool calls add tens of milliseconds per call — policy evaluation, context lookup, and receipt write.

Async: Dashboard logging, analytics, audit writes, and receipt signing are off the critical path and add no latency.

Failure Modes

If Rivaro is unreachable:

• Default: fail-open. Traffic passes through to the provider or tool. Enforcement is skipped. The event is logged for later review.
• Configurable: fail-closed. For high-sensitivity workloads, requests are rejected until governance is restored. This is recommended for financial transactions, PHI access, and other regulated operations.

What Rivaro Sees, Stores, and Retains

Data	Scanned	Stored	Default Retention
Request/response content	Yes	Archived async to cold storage (S3, GCS, Azure Blob, or local)	30 days
System prompts	Yes	Deduplicated, fingerprinted, usage-tracked	Retained with sessions (90 days)
Detection metadata	--	Yes (type, severity, confidence, location)	7 years (SOC2)
Policy decisions	--	Yes (action taken, rule matched, context)	7 years
Enforcement receipts	--	Yes (signed, hash-chained)	7 years
Action records (audit ledger)	--	Yes	1 year
Sessions and telemetry	--	Yes	90 days
Agent identity records	--	Yes	Retained while agent is registered

Retention periods are configurable per organization. Raw content is archived to cold storage before deletion. GDPR deletion and data export are supported.

For detailed data handling, encryption, and compliance information, see Security & Trust.