Skip to content
// Security & trust

Security & trust

  • Runs in your infrastructure.

    Customer-deployed — a single host or your own cluster. Your data never transits a vendor cloud of ours; inference goes straight to your model provider with your keys.

  • Keys stay at the edge.

    Agent CLIs and model API keys live only on workers. Compromising a server doesn't yield them.

  • Signature is auth.

    Worker calls, audit logs, and the policy/agent stores gate on cryptographic signatures — and stores re-verify on read.

  • Fail closed.

    Servers refuse to start without their key material; the broker refuses an empty worker allowlist; unsigned/open modes require an explicit dev flag.

  • Evidentiary audit.

    Hash-chained, signed audit logs on both the control plane and job execution — records that can't be silently rewritten.

  • Right-to-erasure built in.

    One command erases the learning store — whole, or scoped to a single project to offboard it. There's no per-user erasure because there's nothing to erase: the store is de-identified by design, keyed only by project.

// FAQ

FAQ

What agents does it run?

Coding-agent CLIs — Claude Code, Codex, Pi, Antigravity — driven through one adapter layer. The agents themselves are external dependencies; Oktomata launches, routes, and learns from them.

Does Oktomata host models?

No. Inference is always your external provider, with your keys. The LLM gateway is a same-vendor pass-through that adds auth, rate limits, resilience, and telemetry — it never translates between vendors.

Does it record my transcripts?

No. There is no client-side capture and no transcript database. Learning comes from the run's real outcome and from lessons an agent authored after the run. The durable transcript record is the per-agent versioned history — in your infrastructure, like everything else.

Is it multi-tenant?

No — deliberately. One deployment is one tenant. Isolation is the deployment boundary and per-deployment data, not a tenant column on the wire.

What does "self-improving" actually mean here?

Two concrete, shipped loops: outcomes re-reward routing decisions so the map drifts toward the (agent, model) choices that ship working code, and per-project lessons are distilled after runs and recalled into future ones. Plus the KPIs to verify both curves are bending.

Can learning make an agent more dangerous?

No. The worker enforces a fail-closed policy floor — binary override, extra args, child env, and auto-approve each require an explicit worker opt-in. No learned routing or promoted policy can widen a job's power past that floor.

> Let's talk

Stop guessing which agent gets the job. Start grading it.