Govern Overview

Run agents on Recursiv so you can govern and prove what they did

Why govern

Most agent stacks run the model in your code and call out to an LLM. The platform sees prompts and completions but not what the agent actually did with your tools, your data, or your customers. There is nothing durable to point at when someone asks “what did the agent do, and who let it.”

Recursiv is different because the agent runs on the platform. Every identity, every tool call, every approval, and every self-evaluation passes through the same execution layer. That layer is what makes governance and proof possible. You do not bolt on observability after the fact. It is a property of where the agent runs.

This section covers how to govern agents on Recursiv across four pillars, and is honest about what is generally available today versus what is on the roadmap.

The four pillars

PillarWhat it gives youPage
Identity and accessEvery agent and key has a scoped identity. Least privilege by default.Identity & Access
Guardrails and approvalsPer-tool policy (auto / approval / off) and a human approval queue.Guardrails & Approvals
Audit and observabilityA record of agent activity, conversations, tool executions, and task outcomes.Audit & Observability
Self-evaluationAgents grade their own output against criteria and refine before delivering.Self-Evaluation

Identity and access

Agents and API keys carry scoped identities. API keys scope to all of your orgs, a selected set of orgs, or a single org or project. Agents are granted access to specific projects with specific permissions and that access can be revoked at any time. Organization-level security policy controls two-factor enforcement, session and idle timeouts, and IP allowlisting.

Guardrails and approvals

Every tool an agent can call sits under a policy: auto runs immediately, approval queues the call for a human to review, and off removes the tool from the agent’s toolset entirely so the model never sees it. Policy is resolved per tool, per bundle, and from a safe default, with the most specific rule winning. Sensitive categories such as sending email are hardened to require approval regardless of the agent’s mode.

Audit and observability

Because the agent runs on the platform, its work leaves records: tool execution logs, agent conversations, dispatcher signals and outcomes, configuration change history, and per-task activity. You can read these through the SDK and MCP to reconstruct what an agent did and why.

Self-evaluation

The Recursiv Protocol has agents score their own output against the task before they deliver it. If the score is below threshold the agent addresses the gaps and re-evaluates, up to a bounded number of iterations, and the learnings are written to memory. This is how agents catch their own mistakes instead of one-shotting an answer.

What running on the platform proves

When an agent runs on Recursiv you can answer, from records the platform already holds:

  • Which identity acted, and what it was scoped to
  • Which tools it called, whether they succeeded, and what failed
  • Which actions a human approved or rejected, and when
  • How the agent graded its own output before delivering
  • What changed in the agent’s configuration over time, and who changed it

That is the difference between asserting an agent behaved and being able to show it.

Self-hosting and compliance posture

You can run Recursiv on your own infrastructure. The platform deploys via Docker Compose or Kubernetes against your own PostgreSQL, Redis, and S3-compatible storage, so agent data and execution stay inside your environment. See Self-Hosting for the deployment options.

All agent operations are scoped to a network and optionally an organization. API keys are org-scoped, agents are bound to owners and organizations, database queries are filtered by org context, and approval decisions are isolated between tenants. Code execution runs in VM-level sandboxes with no access to platform credentials. See Agent Trust Architecture for the full isolation and policy-enforcement model.

Recursiv maintains a compliance program aligned with SOC 2 Type II Trust Services Criteria, including formal security policies mapped to SOC 2 controls, a tracked risk register, and periodic policy review. For compliance documentation contact compliance@recursiv.io.

Generally available vs roadmap

The pillars above are expressed through real platform primitives that exist today: scoped API keys, agent project access, organization security policy, per-tool approval policy, the human approval queue, tool execution and activity logs, dispatcher signals and outcomes, and the Recursiv Protocol self-evaluation loop. Each page documents the exact methods.

Roadmap: a single one-call Verification product (define a suite of checks, run them against an agent’s output, and gate a release on the result) and a productized Identity product that bundles scoping, SSO, and RBAC behind one resource are not yet built. Where this section describes them, it labels them clearly. Today you compose the same outcomes from the primitives documented here.