ENZO Self-Hosted AI Workspace

The supplied source shows meaningful privilege controls: per-agent tool allowlists, rejection of disallowed calls, exclusion of Gmail-send and calendar-create tools from scheduled runs, explicit opt-in for internet gathering, and HTTPS/private-network/metadata-address guards. The README, CI, and crypto tests also describe a browser vault, encrypted server-side secret files, mode 0600, tamper detection, fail-closed behavior without a master key, key wiping, and a recovery file. Deductions remain because the first validated key automatically claims an instance and is written into container configuration, while actual write-confirmation enforcement is only indirectly evidenced by a context flag and tests. No rollback for completed Gmail or Calendar effects is shown. Statements that keys never enter volumes or are not read by the server do not fully align with the documented claim-key persistence in .env and enzo-memory. Dependency audits block high and critical findings, but no audit result or lockfile contents are supplied. Repository and model provenance are partly recorded, yet package authorship is blank and publisher identity remains unknown.

The evidence covers streamed tool-call assembly, continuation after truncation, agent CRUD, input sanitization, tool authorization, iteration caps, provider fallback, scheduling, SSRF defenses, corrupt-store recovery, and fail-closed encryption. CI additionally defines type checks, tracked-import checks, keyless startup, backend startup, tests, and frontend builds. Provider racing, fallbacks, and conversion of some failures into warnings support ordinary resilience, and many failure messages are specific. The largest deduction is internal inconsistency: the README presents v1.3.0 and Apache-2.0 while package.json reports version 1.0.0 and ISC, and key-location descriptions conflict. Models, search, media, and public-data endpoints remain external dependencies, with not all degradation paths demonstrated in the supplied files.

The README clearly addresses self-hosted users and research, coding, agent-building, and scheduled-automation scenarios. It provides macOS, Windows, and Linux guidance, lite/full images, hosted-versus-self-hosted differences, and optional configuration, earning strong environment-fit credit. Tool allowlists, size caps, internet opt-in, research budgets, loop limits, disabled scheduled writes, time zones, intervals, and provider fallback establish useful boundaries and trigger behavior. Deductions apply because some boundaries remain descriptive: the exact activity collected by self-training, its retention scope, and its trigger semantics are not fully shown, while manual write confirmation and provider-specific capability differences are not completely substantiated by the supplied implementation.

The README has strong navigation and organizes features, quickstart, security, platform setup, configuration, editions, and storage coherently. Installation and routine Docker commands are concrete, including the warning that adding -v wipes data. Examples and troubleshooting cover common startup cases, but there is no dedicated FAQ, and the referenced SECURITY and CHANGELOG contents were not supplied. Metadata stability is weak: examples use both cd enzo and cd ENZO, README/LICENSE say Apache-2.0 while package.json says ISC, and product release v1.3.0 differs from package version 1.0.0. CI establishes that a dated changelog exists and the README summarizes releases, but its actual quality cannot be checked. Update paths and releases are identified, yet package authorship is blank and no maintainer, support channel, security-reporting contact, or response commitment is documented.

The product combines multi-provider chat, agent construction, research, code generation, skills, memory, and Gmail/Calendar tooling in a self-hosted workspace. Streaming output, truncated-code continuation, run records, and surfaced warnings provide reasonable evidence of usable outputs and added value. BYOK operation, free-model racing, hard budgets, and the lack of a subscription can reduce intermediary cost. Deductions apply because many benefit claims are first-party marketing assertions without representative task outputs, quality benchmarks, or resource measurements. Racing roughly ten models may also increase request volume, rate-limit pressure, and the number of providers receiving prompts, while Docker resources, API charges, and maintenance costs are not quantified.

The README connects several security and capability claims to named documents, tests, and CI stages, and the supplied tests/workflow independently support tool restrictions, secret scanning, dependency auditing, keyless boot, encrypted storage, SSRF controls, and scheduler limits. Comments generally distinguish intended behavior from asserted checks. Deductions apply because only part of the repository is supplied: SECURITY, CHANGELOG, core implementations, lockfiles, and several integrations cannot be inspected, nor can exact counts such as 298 tests, 44 pentest assertions, 74 skills, or 300+ models be reconciled here. A CI definition proves that checks are configured, not that this revision passed them. Broad competitor comparisons and claims such as real facts or identical deployed code lack separate corroboration or precise qualification.