We open-sourced our agent platform's governance layer: hexagonal architecture and governed execution

We open-sourced SOIT a few weeks ago. The one
line version: an agent runtime and governance platform for teams that need AI
agents to touch real enterprise systems without losing control.

This post is about the part that is actually hard — not building agents, but
being willing to let them run in production.

The problem isn't building agents. It's trusting them.

Every team I talk to has the same story. The demo took a week and it was great.
Then security, compliance and ops started asking questions, and the project
parked itself at PoC:

• What is this agent allowed to do, and who decided that?
• Where do its credentials live, and what leaks if a prompt goes wrong?
• Which hosts can it reach when a tool call makes an outbound request?
• What exactly did it do last Tuesday, and can we prove it step by step?
• What did that run cost, and which team pays for it?

Frameworks answer none of these — they orchestrate calls and leave controls to
you. Hosted platforms answer some, but you inherit their model choices, their
data boundary and their pricing. Cloud-vendor agent services answer more, in
exchange for the deepest lock-in of all.

Our answer is to make governance a kernel concern rather than a patch applied
afterwards.

Governed execution

The idea is simple to state: every agent run is a governed run. Chat turn,
agent loop, or workflow run — everything flows through one runtime ledger
(Run / RunStep / Trace), and the same controls apply on every path:

• Permissions — tenant and workspace scoping on every resource, RBAC with resource-level grants. Every record carries tenant_id and workspace_id; there are no escape hatches.
• Approved capabilities — agents bind to models, tools, knowledge bases and workflows through per-version allowlists. A tool from a plugin, an MCP server, or a built-in adapter looks identical to the agent and passes the same checks.
• Secret boundaries — credentials live in Vault with workspace-scoped visibility and are injected at the gateway. Business code never opens a raw HTTP client or LLM SDK.
• Egress policy — outbound HTTP from tools is policy-controlled. An agent cannot quietly call a host you never approved.
• Ledger, cost, audit, replay — per-step tokens, latency and cost; a full audit log of privileged operations; a trace timeline you can replay step by step.
• Separation of duties — the Dev role that builds and runs agents cannot change egress policy, secrets, or installed plugins. That takes a workspace Owner or Admin.

None of this is a wrapper around someone else's runtime. SOIT is a hexagonal
architecture: a stable kernel, versioned JSON Schema contracts on every
primitive, and replaceable adapters at the edges — so the governance layer holds
no matter which model or vector store you swap in.

That last property is the whole reason for the shape. Governance implemented at
the integration layer has to be rewritten for every new tool and every new
provider. Governance implemented at the port layer is written once, and every
adapter inherits it whether it wants to or not.

What's in the box

Four pillars, all of them in the open-source edition:

• Build — visual agent assembly with versioning and release management, a DAG workflow editor, a knowledge pipeline (PDF/DOCX/Markdown/HTML into Milvus-backed retrieval), and MCP support: any Model Context Protocol server resolves into the tool registry without code changes, including OAuth 2.1-protected servers.
• Execute — an outbox-based event-driven runtime with checkpoints, retries and fallback chains; multi-model routing across OpenAI, Anthropic, DeepSeek, Qwen and any OpenAI-compatible endpoint — including the one on your own GPU.
• Observe — a workspace console built on the runtime ledger: live run volume, cost burn, failure rates, drill-down by agent, workflow and tool, plus OpenTelemetry tracing and Prometheus metrics.
• Govern — everything in the section above.

It self-hosts with one command:

git clone https://github.com/soit-ai/soit.git
cd soit
cp .env.example .env
docker compose --env-file .env -f docker/docker-compose.yml up -d

A supply chain you can verify

If your agents run in production, so does your agent platform — which makes it
part of your attack surface.

Every SOIT release is built by a tag-triggered pipeline that publishes
digest-addressable images, SPDX SBOMs, Sigstore-backed build provenance and SBOM
attestations, a deterministic source archive, and SHA256SUMS. v1.0.0 shipped
that way: three images on GHCR that pull anonymously, and artifacts you can
check with gh attestation verify before they enter your environment — we ran
it ourselves and got exit 0.

Secret scanning, dependency audit and container scanning run in CI as gates, not
as dashboards.

What SOIT is not

A post like this should also say what you are not getting:

• It is not a lightweight chatbot builder. If you want a prompt box and a share link, plenty of tools do that with far less infrastructure.
• Content safety and PII detection are not implemented. SOIT exposes a content-safety port and an HTTP adapter so you can plug in a classifier you operate, and inspection outcomes become part of run evidence — but with no adapter configured, no inspection happens. I would rather say that than ship a checkbox that does nothing.
• The project is young. v1.0.0 is released and the CI gates are in place, but there is no large-scale production deployment vouching for it yet. We run it ourselves. Early adopters welcome, with eyes open.

License: Apache 2.0

Commercial use, self-hosting, internal deployments and building products on top
are all unrestricted. The core platform is and will remain open source; SSO,
advanced audit reports and multi-region deployment live in SOIT Enterprise. The
commercial boundary is drawn in the feature set, not in the license.

Come break it

The repo is at github.com/soit-ai/soit.
The quickstart takes about ten minutes on a machine with Docker. There are
good first issues seeded and the roadmap is pinned.

If the architecture trade-offs are the interesting part for you — the outbox
runtime, the spec-first contracts, lease-based worker recovery — say so and I
will write those up separately. I also wrote a companion piece on what happens
when an MCP tool call has to obey RBAC, secrets and egress policy:
Five questions to answer before you put MCP in production.

If your agents graduated from notebooks and hit the trust wall, this was built
for you. Tell me where it falls short.

Disclosure: I maintain SOIT.