Suvra

What is Suvra?

Suvra is a policy-first execution control plane for enterprise AI agents. It sits between agent intent and real-world side effects, evaluates declarative actions against deterministic policy rules, and only then allows, blocks, or gates execution via approvals — with full audit logging at every step.

What Suvra is not

Before diving into what Suvra does, it helps to be clear about what it is not:

  • Not a workflow engine. Suvra does not orchestrate agent steps, manage state machines, or define task graphs. Your agent framework handles orchestration — Suvra enforces the boundary between intent and execution.
  • Not an LLM wrapper. There is no language model anywhere in the enforcement path. Suvra does not interpret, summarize, or rewrite agent actions. It evaluates them deterministically against your declared policy.
  • Not a prompt guard. Suvra operates at the action layer, not the prompt layer. It does not inspect, filter, or modify LLM inputs or outputs. It evaluates the structured actions that agents request to execute.

Two deployment modes

Suvra supports two deployment modes that can be used independently or together:

Control Plane

The full Suvra deployment — dashboard, admin interface, policy management, approval workflows, audit explorer, agent registry, and node management. This is the central coordination layer for production deployments.

  • Postgres backend for production
  • Role-based access control (Viewer, Operator, Policy Admin, Admin)
  • Policy versioning, publishing, and bundle distribution
  • Approval workflows with identity-checked integrity
  • Full audit trail with explainability traces

Enforcement Node

A lightweight Suvra runtime deployed close to your agents. Enforcement Nodes enforce policy locally against a cached active policy bundle, continue operating when the Control Plane is temporarily unreachable, and forward approvals and audit events when connected.

  • Runs near the agent for low-latency enforcement
  • Caches the active policy bundle locally
  • Fails closed when the Control Plane is unreachable
  • Spools audit events and forwards them on reconnection

Core architecture flow

Every agent action flows through the same deterministic pipeline:

  1. Agent submits a structured action request (action type, parameters, identity context)
  2. Enforcement Node receives the request and evaluates it against the local policy cache
  3. Policy Engine performs pure deterministic rule matching — no LLM, no heuristics
  4. Decision is returned: allow, deny, or needs_approval
  5. Executor runs the side effect only if the decision is allow (or an approved needs_approval)
  6. Audit Log persists the full trace — identity, action, matched rule, decision, and explainability context

Core guarantees

Deny-by-default

If no rule matches an action, the action is denied. This is a hard guarantee, not a configurable setting. There is no mode, flag, or environment variable that changes this behavior. If you haven't written a rule that matches, the action does not execute.

Deterministic enforcement

Every policy decision is the result of pure rule matching against your declared YAML policy. There is no language model, probabilistic classifier, or heuristic in the enforcement path. Given the same policy and the same action context, Suvra will always return the same decision.

No LLM in the enforcement path

This is worth repeating: there is zero LLM involvement in any enforcement decision. The policy engine is a deterministic rule matcher. This is a design constraint, not a limitation.

Approval integrity

When an action resolves to needs_approval, the approval record captures the actor, action type, and a hash of the action parameters. When the agent re-submits the action with an approval ID, Suvra verifies that the approval matches the exact action context. A modified action with a recycled approval ID is rejected.

Rollback capture

Executors capture rollback payloads at execution time. If a fs.write_file action overwrites a file, the original content is captured before the write. Rollback payloads are persisted to the audit database and survive process restarts.

Audit-first design

Every validate, execute, approval state transition, and rollback operation is persisted with full identity context, the matched rule, the decision, and a business-readable explainability trace. The audit log is not optional — it is a core part of the enforcement pipeline.

Simulator safety

Action types like shell.exec, email.delete, and secrets.read are recognized by the policy engine and simulator but are never executed. They fail closed at the executor boundary. You can write policy rules for them, simulate them, and audit their decisions — but Suvra will never run them.

Defense in depth

Suvra enforces multiple layers: policy evaluation, approval gating, executor-level type checking, rollback capture, and audit persistence. A failure at any single layer does not silently pass an action through.