Skip to main content

Governance is the differentiator

If you read one page before deciding whether Culvii fits your stack, read this one.

The case in one paragraph​

Most agent frameworks treat audit trails, permission boundaries, and human approval as things you bolt on after the framework does its job. That's fine for a prototype. It doesn't survive the question "who told this agent to do that, and on whose authority?" Culvii writes the audit log at the platform layer, so you can't forget to import it. It scopes tool access per agent instead of per process, and makes human approval a step in the workflow graph instead of a Slack message someone has to remember to send. If you don't need any of that, Culvii is more machinery than you want. If you do, it's cheaper to start with a platform built around it than to retrofit one that wasn't.

What we actually enforce today​

Audit by construction​

Every action, model call, tool call, deploy, workflow resume, lands in an append-only audit table. There's no UPDATE, no DELETE. Each event records who did it (the user, via their OAuth session, see Authentication), what the action was, when, the result, and a correlation ID tying it to the rest of the run.

You don't add this by importing a logging library. The platform writes it whether your tool code remembers to or not.

Tool access scoped per agent, not per process​

An agent only sees the tools you explicitly grant it, and grants don't leak sideways. If a primary agent delegates to a secondary with workflow:binary:read, the primary still can't read binary files unless it's granted that permission too. Built-in permissions are a closed, typed set. The SDK rejects unknown keys, and the platform validates them again at deploy time regardless of what the SDK let through. See Tools and permissions.

Human approval as a workflow step, not a side channel​

A step can pause on a Surface in its wait slot and stay paused, for seconds or for weeks, until someone acts through node.resume or node.stop. It's part of the graph, not something the agent has to remember to ask for. See Human in the loop.

What we're honest about not having yet​

  • Per-agent cryptographic identity. Today, attribution runs through the user who acted, not a DID issued to the agent itself. See Identity and audit attribution.
  • A developer-facing audit query API. The table is written from day one; querying it programmatically (versus through the Console) isn't public yet.
  • Fine-grained, declarative per-resource policy. Today's roles (owner, admin, operator, developer, viewer) are coarse. A permit()-style policy model is on the roadmap.

What we don't claim​

We don't claim compliance certifications like SOC 2 or ISO 27001, whatever your auditor asks for, as a feature you turn on. Compliance is your process; we try to build the primitives that make it tractable. We also don't replace your IAM: human identity federates to your existing IdP (Google today; SSO on the roadmap).

When this gets in your way​

For a ten-line proof of concept, an audit log and scoped permissions are overhead you don't need yet. That's fine. Prototype somewhere lighter and move here when the governance properties start to matter, rather than fighting them before they do.

Human in the loopSee how wait surfaces pause a run for approval.Identity and audit attributionWhat's actually attached to an audit event today.