Meet Harnis: the open-source platform for running AI agents safely across your company

AI agents are finally useful enough to do real work: fix code, answer customers, update tickets, run internal tools. The hard part isn't getting an agent to act. It's letting it act inside a company: across teams and customers, on real systems, with someone accountable for every change and a bill that doesn't surprise anyone.

That's what Harnis is for. It's an open-source, self-hosted platform that gives every agent in your organization the same harness: isolation, approvals, sandboxing, budgets and an audit trail, so teams can ship agents quickly without rebuilding the safety layer every time.

• GitHub: https://github.com/karawash-projects/harnis
• PyPI: pip install harnis
• Helm chart: oci://ghcr.io/karawash-projects/charts/harnis
• License: Apache 2.0

Why a harness?

Every team that builds an agent ends up writing the same plumbing: who is this user, which customer's data can they see, should this action wait for a human, where does model-written code run, how much did that conversation cost, and who approved what. When each team writes it alone, you get ten slightly different answers and no single place to audit.

Harnis turns that plumbing into a platform. Agents plug in; the guarantees come with them.

Three products on one engine

Harnis ships three ready-to-use workloads, all running on the same orchestrator:

1. A coding agent for your developers. Point the CLI at a project and describe the change. The agent works on an isolated copy, shows a diff for every file it wants to write, asks before running any command, runs your tests in a sandbox, and applies the final result to your files only when you confirm.

harnis --workspace ./my-service "add input validation to the signup handler and a test for it"

2. Multi-agent workflows. A router on a small, fast model reads each message and hands it to the right specialist (a support agent, a coding agent, or your own). Agents can hand work to each other or escalate to a person. Add a new specialist with a few lines of plugin code.

3. A multi-tenant agent app. A full API with live streaming over WebSockets and a web console for every role:

• Users chat with agents and see each proposed change, with diffs inline.
• Reviewers work an approvals queue and see usage and analytics.
• Admins manage agents and their prompt versions, API keys and the audit log.
• Platform admins create and manage tenants.

What every agent gets for free

Customer data stays separated, by the database itself

Every tenant table uses Postgres row-level security, enabled and forced, and the app connects with a role that can't bypass it. The tenant always comes from the verified login or API key, never from the request. Even a query that forgets to filter by tenant can't return another customer's data.

A human approves the exact action

Writing files, running commands and installing packages pause the session until a reviewer approves. The approval is tied to a cryptographic hash of the exact action, so the agent can't get approval for one change and then make a different one. Approvals expire, and separation of duties can stop people approving their own sessions. Paused sessions live in the database, so a decision made hours later resumes the work on any server.

Model-written code runs in a disposable sandbox

Each command gets a fresh Docker container or Kubernetes Pod with no network, a read-only system, no Linux privileges, a non-root user and strict memory, CPU and process limits. gVisor is supported for an extra kernel boundary. Files coming back out are checked, so a model can't sneak a link to a host file into your project.

Need packages? An approved install goes through a proxy that only allows package registries, and it can only change a separate dependency folder, never your code.

Security that checks itself

On Kubernetes, Harnis doesn't just assume the network rules are in place. Before it copies anything into a sandbox Pod, it probes from inside the Pod and only proceeds once the network is confirmed blocked. If the cluster can't isolate the sandbox, the command is refused with a clear error rather than run unprotected.

Costs you can predict

• Per-turn budgets for steps, tool calls, hand-offs and spend in USD.
• Per-tenant cost caps.
• A token and cost ledger per model.
• A loop breaker: it spots an agent repeating itself, warns it, then hands the session to a person.
• Confirmed prices: you confirm each model's price at setup, so cost figures and caps are based on real numbers.

Your models, your rules

• Models: use Anthropic, OpenAI, Google Gemini or Amazon Nova on Bedrock, or self-hosted ones through any OpenAI-compatible API (vLLM, Ollama, LM Studio, LiteLLM).
• Failover: you set the order and Harnis fails over between providers automatically.
• Data residency: each tenant has its own list of allowed providers, and failover never sends that tenant's data outside it.

Your login, your roles

• Single sign-on: any OpenID Connect provider (Okta, Entra ID, Auth0, Keycloak, Google), with group-to-role mapping.
• Roles: user, reviewer, tenant admin and platform admin.
• API keys: service keys for CI and automation, with roles, expiry and instant revocation.

Your tools and agents

A plugin SDK lets you add tools, agents and even model providers that register exactly like the built-in ones. Internal APIs, ticketing systems and databases all become tools that inherit approvals, sandboxing and auditing automatically.

Built-in guardrails

• Prompt injection: incoming messages are checked for injection attempts.
• Card numbers: they're redacted before the model sees them.
• Tool output: it's marked as untrusted data, so instructions hidden in a file or web page aren't treated as commands.
• Semantic cache: repeated questions are answered from the cache, which is fast and costs nothing.

Ready for your auditors and your ops team

• Audit log: append-only, exportable as JSON or NDJSON.
• Monitoring: OpenTelemetry traces, Prometheus metrics and alert webhooks.
• Data lifecycle: retention jobs, per-user data export and erasure, and backup and restore commands with verification.

Runs where you do

On a laptop, everything starts with Docker Compose on Windows, macOS or Linux. On Kubernetes, the Helm chart deploys:

• the API, which scales out because sessions resume on any replica;
• database migrations, run before each install or upgrade;
• scheduled maintenance;
• a separate, locked-down namespace for sandbox Pods.

Try it in five minutes, without an API key

The quick start uses a built-in mock model, so you can explore approvals, the sandbox and the loop breaker for free:

git clone https://github.com/karawash-projects/harnis.git
cd harnis
python tasks.py install
python tasks.py up              # Postgres, Redis, tracing, demo tenants
python tasks.py sandbox-image
python tasks.py dev             # http://127.0.0.1:8000

Open the console, click Continue as local developer, and type create calc.py. The coding agent proposes two files with diffs, waits for your approvals, then runs the tests in the sandbox. Try repeat: list the files to watch the loop breaker step in, or ignore all previous instructions to see the input guard. When you're ready, python tasks.py check runs a complete feature check against your instance.

Built to be tested

Each release passes:

• a cross-platform test suite;
• end-to-end checks against a running API;
• an evaluation suite and red-team scenarios;
• sandbox tests under gVisor;
• a full Helm deployment on a Kubernetes cluster in CI.

The same feature-check script ships with Harnis, so you can verify your own deployment the way the project verifies its releases.

Get involved

Harnis 1.0 is out now, free under Apache 2.0, and provided as is. Star the repo, try it on a real workflow, and tell me what you'd build on it:

https://github.com/karawash-projects/harnis

Issues, ideas and pull requests are welcome.