- 01Software that runs inside the perimeter with access to production systems should be readable by the people responsible for that perimeter. The Hubzoid core is open under MIT at github.com/hubzoid/hubzoid for that reason.
- 02The core is the whole runtime: framework, access control, scheduling, evals, gateway, surfaces. The paid part is delivery, meaning discovery, world models, connectors, and operation. It is not a crippled edition with the real product behind a paywall.
- 03A security reviewer should start with the access guard and audit log, then the scheduler, then the deployment and observability docs, and should read the caveats as carefully as the features.
An internal agent is an unusual piece of software to bring inside a company. It reads the ERP. It reads the accounts. It runs on a schedule with nobody watching. It sends messages to the owner. Any of those, done wrong, is a problem that lives inside the perimeter, behind the login, where the company's own controls are the only ones that apply. The position Hubzoid takes is simple: software with that kind of access should be readable, line by line, by the people responsible for it.
So the core is open. It is on GitHub at github.com/hubzoid/hubzoid under the MIT license, which means it can be read, run, forked, and modified with no obligation to Hubzoid. A security team can clone it before a first call. That is the intended order of operations.
What follows is what the core contains, framed by what it does precisely rather than by what a sales page would say. Each item maps to a file a reviewer can open.
01. The framework. Knowledge as markdown files. Skills loaded on demand. Tools as typed Python functions. Sub-agents with explicit tool whitelists. The hub a company runs on is a repository of these, versioned like any other code, which is what makes decision logic something a reviewer can diff rather than something that lives inside a model.
02. Access control. Sensitive tools are gated by team group. When the model attempts a tool the user's group is not allowed to use, the call is denied at execution, outside the model, so no phrasing of the request changes the answer. Each allow or deny decision is written to an append-only audit log. The precise caveat: the log is best-effort, so a failure to write does not stop the agent, and what it records is the allow or deny at the point of invocation. Read access/guard.py and access/audit.py and confirm that yourself.
03. Scheduling. Tasks run unattended on cron or on a webhook. Each run is bounded, scoped to a path, and logged. A task that maintains its own state file can resume after an interruption. A task that does not, cannot. That caveat is in schedule_runner.py, and it matters for anything that runs overnight.
04. Evals. Behavioral evals that run in development, in CI, and on a schedule, so that a change to a world model or a threshold is checked against expected behaviour before it reaches the team. Observability beyond that is opt-in: OpenTelemetry traces can be sent to your own collector or to Langfuse, but tracing is off by default and is not instrumented across every call in the core. Do not read the presence of an OTel module as full tracing.
05. The gateway. Many hubs behind one login through Open WebUI, with discovery gated by group, so the finance hub is visible to finance and not to the floor. The caveat: isolation depends on correct provisioning and group configuration, and a provisioning failure does not stop the system from booting. A reviewer should check the deployment doc, docs/DEPLOYING.md, and verify the provisioning step in their own environment rather than assume it.
06. Surfaces and identity. One agent reaches Slack, Telegram, WhatsApp, the web, a generic webhook, an OpenAI-compatible API, and an MCP server, sharing the same knowledge, skills, and tools. Conversation history is kept per surface, not merged across them. Email is on the roadmap and is not shipped. Sign-in runs through Open WebUI with Google, Microsoft, GitHub, OIDC, or LDAP. The runtime underneath is a choice between the OpenAI Agents runtime and the Claude runtime, routed through LiteLLM or a local Claude, and further runtimes are roadmap, not present.
One more caveat, because it is the one most often overstated. The core self-hosts in your cloud, and that is what keeps your data inside your perimeter. Whether a model provider trains on your traffic is governed by that provider's enterprise or zero-retention terms, which you hold, not by anything in the core. The honest sentence is: self-hosting plus your provider's terms. Not: the core guarantees it.
The model is free core, paid delivery. Anyone can run the core. A company with an engineer who will own it can deploy it, write its world models, wire its connectors, and operate it, and owes Hubzoid nothing. A company without that person, which describes most owner-led companies of a hundred to a thousand people, hires Hubzoid to do the delivery: discovery, the catalog, the first agent and the hub, connectors into the real ERP and the real accounts, handover, and operation for as long as the engagement says. The price is fixed, set against the cost of the work the agent recovers.
This is not a bait-and-switch, and the test is simple. The open core is the same code that runs inside a paid engagement. There is no enterprise edition with the access control turned on and a community edition with it turned off. What the engagement adds is work, not features: the company-specific decision logic, the connectors into messy systems, the silent-data-bug checks written for that company's exports, and the people who watch the first month. Ownership of that work product is a term of the engagement contract, which is the right place for it, rather than a claim about the license.
For a security reviewer with an afternoon, the order is this. Start with access/guard.py and access/audit.py, because tool gating and its log are the controls the rest depends on. Then schedule_runner.py, because unattended execution is where an agent does the most with the least supervision. Then docs/DEPLOYING.md for provisioning and gateway isolation, and docs/OBSERVABILITY.md for what is and is not traced. Then the README, which lists surfaces and the roadmap in plain terms. Read the caveats in each as carefully as the features. A weaker claim that is true beats a stronger one that is not, and the repository is where that gets checked.
The reason to buy an internal agent from anyone is trust in what runs inside the perimeter. The reason to buy from a firm whose core is open is that the trust can be checked rather than extended. Clone it. Read the guard. Then talk.