Skip to main content

Production Readiness

Manasvi is designed for governed, auditable agent execution, but the repository should still be treated as a pre-production reference implementation unless you have reviewed and hardened the deployment for your threat model.

The important distinction is this: the security architecture is real, and several Track A hardening items have landed, but not every production dependency is complete.

What Track A hardened​

Track A focused on making the existing design production-real instead of adding new surface area.

AreaCurrent status
Shell command allowlistHardened. Shell command execution now uses an operator-controlled server-side allowlist via EXECUTION_SHELL_ALLOWED_COMMANDS; callers cannot authorize their own commands.
Extension runtime management APIHardened. Plugin management routes require authenticated internal principals.
Policy decision auditHardened. Policy decisions are forwarded to the audit service; the in-memory policy buffer is only a fast local view.
Replay/idempotency protectionHardened for configured local durability. Execution-manager, node-manager, and node-agent can use durable consumed-set storage so consumed artifacts and nonces survive restarts.
Memory durabilityImproved. The memory plane supports optional JSONL persistence through MEMORY_PERSISTENCE_FILE; sensitive memory remains encrypted at rest.
Asymmetric signingPrimitive available. ECDSA P-256 signing and verification support exists in the executor SDK, but service-wide key configuration and rollout are still pending.
Native-process sandboxingMitigated, not finished. Tools that require native isolation are refused unless EXECUTION_SANDBOX_CONTAINERIZED=true; full container/gVisor/microVM isolation remains milestone-scale work.

For the internal implementation record and verification commands, see docs-internal/progress/track-a-production-hardening.md.

Remaining Production Constraints​

Durable agent runs and async approval resume​

When a proposed action requires approval, Manasvi can now persist the paused run, persist approval queue/callback state, and resume orchestrator after approve/reject decisions. Configure ORCHESTRATOR_AGENT_RUN_STORE_FILE and APPROVAL_STATE_FILE before relying on this across restarts.

The built-in stores are local JSON/JSONL stores. They are useful for a single-node deployment and local restart durability, but multi-instance deployments need a shared durable backend and a full service-stack validation pass for the approval resume path.

Full OS-level sandbox isolation​

The JavaScript sandbox constrains Node standard-library access. It is not enough for untrusted native code, shell commands, native addons, or hostile process trees. For those workloads, run the execution manager inside an OS-isolated backend and keep native-isolation-gated tools disabled until a real container, gVisor, or microVM backend is deployed.

Service-wide asymmetric signing​

ECDSA support exists in shared validation code, but production deployments should wire services so signers hold private keys and verifiers hold public keys. Until that rollout is complete, HMAC signing remains the compatibility path and every verifier with the shared secret has signing power.

Multi-instance durable state​

Local JSONL durability is useful for restarts, but multi-instance deployments need a shared durable backend for consumed nonces, idempotency keys, memory, approvals, node registry state, clarification state, and agent-run records. SQLite can be enough for local single-node operation; deployed systems should use Postgres, Redis, or another operationally managed store depending on consistency and TTL needs.

Production checklist​

  • Keep all internal service ports private.
  • Require authentication on every management and internal route.
  • Configure EXECUTION_SHELL_ALLOWED_COMMANDS deliberately; leave it empty to deny shell execution.
  • Leave native-isolation-gated tools disabled unless the execution manager runs with real OS isolation.
  • Configure durable replay stores for execution-manager, node-manager, and node-agent.
  • Configure MEMORY_PERSISTENCE_FILE or a stronger memory backend if memory must survive restarts.
  • Configure ORCHESTRATOR_AGENT_RUN_STORE_FILE and APPROVAL_STATE_FILE for approval resume durability.
  • Confirm policy decisions are reaching the audit service.
  • Use production-only secrets and rotate local development keys.
  • Plan asymmetric signing rollout before allowing verifiers to run in less-trusted environments.
  • Validate approve, reject, timeout, and replay behavior for the approval resume path before exposing it to production users.