Secure by design, not by accident.
The Harness treats security as infrastructure, not an afterthought. Sandboxed execution, explicit review gates, content capture disabled by default, and a clear production checklist.
The harness lives outside the sandbox.
Most AI agent frameworks place the orchestration layer — credentials, API keys, access policies — inside or alongside the execution environment. When the model can reach them through tool calls or environment variables, so can an attacker with a prompt injection. PURISTA takes the opposite approach: the Harness runs in your application process. Only typed tool inputs ever cross the process boundary. Secrets never enter the sandbox.
- API keys and credentials stay in your application process — never injected into the sandbox environment.
- Only typed, schema-validated tool inputs cross the boundary. No raw strings, no env vars, no secrets.
- The sandbox handles execution only: LLM calls, file ops, and commands — nothing sensitive is visible there.
- Even under successful prompt injection, the model cannot reach keys it was never given.
Four pillars of safe AI
Every agent runs in a controlled sandbox with explicit resource limits and timeout boundaries. File operations, tool calls, and MCP servers all respect the same boundary.
- inMemorySandbox() — file-only, no command execution
- bashSandbox() — command execution through just-bash
- Custom adapters for containers or remote execution
- Explicit executor availability: unavailable vs available
No mutation before approval. Review gates block write tools until a human explicitly approves. Full OTel trace for every decision.
- Visible review questions with recommended answers
- Immediate answer capture on selection
- Idempotent final decision submission
- Stale run/review IDs fail with clear errors
Content capture is disabled by default. Prompts and responses are not persisted in traces or logs unless explicitly enabled for local diagnostics.
- captureContent: false by default
- Enable only for deliberate local diagnostics
- OTel spans include metadata, not content
- Application owns data residency decisions
Every agent input, output, and tool call is schema-validated. No unvalidated data flows from the model to your application code.
- Zod schemas for all inputs and outputs
- TypeScript inference through the entire chain
- Tool input/output validation with normalized errors
- MCP schema validation before tool registration
Controlled execution
Choose the right sandbox for your risk profile. File-only for safe agents. Command execution only where needed. Custom adapters for containers or remote isolation.
- inMemorySandbox() — file operations, no commands
- bashSandbox() — command execution through just-bash
- Custom Sandbox/SandboxSession for containers
- Snapshot, resume, and hibernate capabilities opt-in
- Preview ports and browser routing stay application-owned
No mutations without approval
When an agent proposes a change, the workflow creates a ReviewRequest. The user sees questions, selects answers, and submits a decision. Only approved changes execute write tools.
- Proposal agent drafts the change
- Workflow creates ReviewRequest with questions
- User selects answers in questionnaire UI
- Decision submitted — approved, revise, or reject
- Write tool executes only on approved
- All steps traced and logged
Eight decisions before go-live
Each item is a boundary. Get it right once, and every agent you build inherits the safety.
Use a durable adapter so sessions, run history, and OTel traces survive process restart. In-memory state is fine for local development. Production needs persistence.
Define session IDs that include tenant boundaries. A session ID like tenant-a:user-42 prevents cross-tenant data leakage by design.
Set runTimeoutMs, modelTimeoutMs, and toolTimeoutMs for each path. User-facing routes get smaller budgets. Background research gets larger ones.
Keep captureContent: false outside local diagnostics. Never log PII, secrets, or model prompts in production traces. OTel spans include metadata, not content.
Use review gates or explicit permission checks before any mutating built-in tool. No write should happen without either workflow approval or explicit authorization.
Use inMemorySandbox() unless command execution is explicitly required. Never grant more than needed. The sandbox is an adapter — choose the right isolation level.
Test provider failures, validation failures, cancellation mid-run, and graceful shutdown paths. The Harness provides test harnesses and scripted models for deterministic failure simulation.
Never trust model-generated tool inputs. The Harness validates with Zod before execution, but your tool handler should also defend against edge cases. Return structured data. Respect signals.
Build AI that your team trusts.
The Harness gives you the structure, safety, and observability that enterprise AI requires — without the SaaS lock-in.