Open source AI agents:
why a governance tool has to be inspectable.

Open source is a preference for most software and a requirement for one kind: the tool whose whole job is to be trusted. A platform that governs your agents is making promises about logging, permissions, and where your data goes. If you cannot read its code, those promises are exactly as good as the vendor's word. This guide is about why that matters more here than almost anywhere else.

Open source AI agents run on a platform whose code is open: you can read it, audit what it does, modify it, and host it yourself. For most software that is a nice-to-have. For the software that governs your agents, it is closer to a prerequisite, and this guide explains why, along with the distinctions (open source versus open core, what a license like AGPL actually demands) that decide whether the openness is real or cosmetic.

We build Pinchy, an open-source (AGPL-3.0) agent platform, so we have a clear bias. We will try to earn it by being equally clear about when open source is the wrong call.

The audit-the-auditor problem

Here is the argument that makes this topic different from the usual open-source debate. A governance platform exists to make your agents trustworthy: it promises to record every action in an audit trail, to enforce that an agent can only use the tools you granted, and to keep your data where you put it. Those are the product. Now ask the obvious question. If the platform's code is closed, how do you know it actually does any of that?

You do not. You take it on faith. A proprietary audit trail is a black box asserting that it logged everything; you cannot check that it did not drop the inconvenient entries. A proprietary permission engine asserts that it blocked what it should; you cannot check for the exception that lets something through. For a tool whose entire value proposition is that it can be trusted, being un-inspectable is a quiet contradiction. Open source resolves it: the claims become verifiable instead of asserted. You can read exactly how the audit signature is computed, exactly how a permission is enforced, and confirm that the thing watching your agents is doing what it says.

Open source, or open core

Not all "open source" is the same, and the difference is sharpest precisely for governance tools. Open source means the code is open. Open core means a basic version is open while the valuable features are proprietary and paid, and those features are very often the security and governance ones: single sign-on, the audit log, role-based access control. So with an open-core governance tool, the parts you would most want to inspect are exactly the parts behind the paywall, still a black box, just a smaller one.

The test is not whether a project calls itself open source. It is where the governance lives. If the audit trail and the permission model are in the open code, you can verify them. If they are in a closed "enterprise" tier, the openness does not reach the part that matters. It is worth two minutes to check which side of that line a platform sits on before you rely on the word.

Lock-in: who holds your agents

The other reason is portability. Your agent platform accumulates things that are painful to lose: your governance rules, your audit history, your integrations, the configuration of every agent. With proprietary software, all of that lives on the vendor's terms, and leaving means losing access to it in a way the vendor controls. The current enterprise framing puts this as a two-dimension decision, how much you trust the vendor's AI and how much lock-in you accept in return (Kai Waehner). Open source moves you toward the low-lock-in corner: you can read the data formats, run the software without the vendor, and fork it if it ever comes to that. Your exit becomes a decision you can make rather than a position you have to negotiate from.

What if the vendor goes away?

There is a sharper version of the lock-in worry, the one people raise about any small or new project: what happens to you if the company behind it disappears? It is a fair question, and it is where open source is strongest. With a hosted proprietary platform, the vendor going away is an outage followed by a data-extraction scramble: your agents stop, and your audit history and configuration sit on infrastructure you do not control. With an open-source, self-hosted platform, the vendor going away does not decide whether your deployment runs. The software is already on your machines. Your data, your governance rules, and your audit trail are already in your own database. The source is public under its license, so you, or anyone you hire, can keep maintaining it. You lose official updates and support, which is a genuine cost, but the system keeps running. The chance that a small vendor disappears is real for every small vendor. Open source is what changes the consequence from a system that dies with the vendor into one you keep running and control.

What AGPL actually means

License copyleft scares people more than it should, so the honest version: AGPL-3.0 lets you use, self-host, and modify the software freely. Its one distinctive condition is the network clause. If you modify the software and then offer that modified version to others as a network service, you have to make your modified source available to those users. That is it. A company running the platform for its own internal use, even with heavy modifications, never triggers the obligation, because it is not offering a service to outside users. AGPL is a license that stops the software from being quietly taken closed-source. It is not a license that restricts ordinary self-hosted use, which is the use almost everyone has.

When proprietary is the right call

To keep ourselves honest: open source is not free of cost, it trades operational burden for control. A managed proprietary platform deploys faster, and someone else keeps the lights on. If you do not need to verify the internals, you are comfortable with the lock-in, and speed is what you are optimizing for, a proprietary tool is a reasonable choice and we are not going to pretend otherwise. The rule of thumb that holds up: the more an agent's wrong action could touch money, customers, legal exposure, or regulated records, the more the ability to audit the platform and to leave it is worth the responsibility of running it yourself. Low-stakes automation can lean toward convenience. Governance over consequential actions leans toward the open, inspectable option.

How Pinchy approaches it

This is the part about our own product. Pinchy is AGPL-3.0, and the openness reaches the part that matters: the audit trail and the permission model are in the open code, so you can verify that they do what we say rather than trust us. One honest nuance to state plainly: Pinchy uses a license key to unlock some team and enterprise features, but the code behind those features is open too, the key gates the feature, it does not hide the source. That is a deliberate choice to avoid the open-core trap where the governance is the closed part. The platform is self-hosted with no lock-in, so leaving is yours to decide. We made it open because a tool that asks you to trust it with your agents should be able to show its work, and that is the whole argument on this page pointed at ourselves. And it includes outliving us: Pinchy runs entirely on your own infrastructure, validates its license offline with no server to call home to, and keeps no telemetry, so a deployment keeps running whether or not we do.

Frequently asked questions.

Why does open source matter for an AI agent platform?

Open source lets you read the code, audit what it does, control your own updates, and avoid being locked into one vendor. It matters most for the part of the stack whose entire job is trust. A platform that governs your agents claims to log every action, enforce every permission, and keep your data in place. If its code is closed, those are claims you have to take on faith; if it is open, they are claims you can verify.

What is the difference between open source and open core?

Open source means the code is open. Open core means a basic version is open while the valuable features, often exactly the security and governance ones like SSO, audit, and access control, are proprietary and paid. The catch with open core for a governance tool is that the features you would most want to inspect are the closed ones. It is worth checking whether the governance lives in the open part or behind the paywall.

Does open source prevent vendor lock-in?

Largely, yes. Your agent platform holds your governance rules, your audit history, and your integrations. With proprietary software, leaving means losing access to all of it on the vendor's terms. With open source you can read the data formats, run the software yourself, and fork it if you must, so your exit is a decision rather than a hostage negotiation. The trade is that you take on more responsibility for running it.

What does the AGPL license actually require?

AGPL-3.0 lets you use, self-host, and modify the software freely. Its one notable condition is the network clause: if you modify it and offer it to others as a network service, you must make your modified source available to those users. For a company running it for its own internal use, even heavily modified, that obligation does not trigger. The license protects the software from being taken closed-source, it does not restrict normal self-hosted use.

When is a proprietary AI agent platform the better choice?

When speed and low operational burden matter more than inspectability and control. A managed proprietary platform deploys faster and someone else runs the infrastructure. The trade is trust and lock-in: you cannot verify what it does and leaving is harder. The honest rule of thumb is that the more an agent's wrong actions could affect money, customers, legal exposure, or regulated records, the more the verifiability of open source earns its extra responsibility.

Is a small or new open-source AI agent vendor a risk?

Less than a small proprietary one. With a hosted proprietary tool, the vendor disappearing is an outage followed by a data-extraction scramble, because the software and your data live on their infrastructure. With an open-source, self-hosted platform the software already runs on your own machines and your data and audit trail are already in your own database, so the deployment keeps running regardless. The source is public under its license, so you or a contractor can keep maintaining it. You lose official updates and support, but not the running system. Open source turns vendor-survival risk from a system that dies with the vendor into one you keep running and control.

Trust the tool you can read.

Pinchy is AGPL-3.0, with the audit trail and permission model in the open, self-hosted with no lock-in. Verify what it does instead of taking our word for it. Free to run.

Or email us: info@heypinchy.com