JiCoRedact. Approve. Document.

Why we do not build this ourselves

Not every part of JiCo is built in house. Only the part that no vetted tool on the market actually covers.

Background · 2026-09-19 · 6 min read

Checked against the source: LiteLLM handles redaction, neither component holds write actionsRedaction before the modelHold write actionLiteLLMyes, also in tool argumentsno, allowlist onlyBifrost (free)no, Enterprise onlyno, Enterprise onlyResultLiteLLM stays a candidatebuilt in-houseCorrection: Docker MCP Enterprise Gateway also holds calls.The difference lies in order and kind.

An objection worth taking seriously

"Then let us just build it ourselves — with LiteLLM for the redaction and Presidio for the detection." This sentence comes up in practically every technical conversation about JiCo, usually from an experienced platform team that knows perfectly well such building blocks exist and that it can handle them in principle. It is a reasonable first thought, not a naive one — and for exactly that reason it deserves a serious answer rather than a reflexive "that is more complicated than it looks".

The serious answer for JiCo is: this route was genuinely examined, not merely considered and then discarded because building in house suits the business model. There is a clear ground rule the project holds itself to: where a proven standard tool solves a task reliably, it is connected, not rebuilt. In-house development is expensive, error-prone and ties up attention that is then missing elsewhere — it is only worth it where it makes a real, differentiating difference.

What the examination of the actual source code found

The examination of LiteLLM went beyond reading the documentation — it was carried out on the actual source code and in a run against a Presidio substitute system, not merely asserted. For the actual task of redaction before the model, LiteLLM does deliver what the documentation promises: placeholders are resolved correctly, even in tool arguments — that is, in precisely the case JiCo needs, when a model is to formulate a tool call containing a redacted value and that value has to be converted back into the real text at the end.

For the second, at least equally important task — holding writing actions for a human approval — that does not hold. LiteLLM's tool permissions work as an allowlist: a tool is either permitted or it is not, but there is no built-in mechanism that halts a concrete, already formulated write operation and presents it to a human for a case-by-case decision. The second candidate examined, Bifrost, provides in its freely available edition neither a comparable layer of protection for personal data nor a full MCP gateway — both would only be included there in the commercial enterprise variant, which for the core of a product that promises independence from any single vendor would be the most expensive dependency imaginable.

The result of this examination is therefore not a blanket "it does not exist on the market". It is more precise: LiteLLM was examined and found viable for the redaction and remains a candidate. The approval gate remains built in house — not because nobody else has ever built anything similar, but because the two building blocks concretely examined do not solve this one decisive task.

The sentence that went too far — and the correction of it

An honest examination also includes correcting one's own earlier statements when they turn out to have been too sweeping. One sentence from that original examination read: "No tool on the market holds writing actions for a human." That was true of the two candidates specifically examined. It was not true as a statement about the market as a whole — and that is exactly where the sentence stood at first, in the most sensitive of all possible places: in the project's own internal guardrail and in the public competitive comparison, in other words precisely where a careful buyer or a technically versed partner would be most likely to check it.

Docker MCP Enterprise Gateway does exactly that: it holds a tool call by means of a rule and presents it to the client for confirmation, fail-closed — if the confirmation cannot be obtained, the call is rejected rather than let through. The sentence was corrected in the same place where it had previously been phrased too broadly, not quietly qualified somewhere else.

What is left of the correction — and why it is the actual distinction

This correction did not weaken the distinction; it made it more precise and thereby more durable. The difference from JiCo no longer lies in the blanket claim that something is held — other systems demonstrably do that too by now. It lies in the order and the manner in which it happens: redacted before the model, not filtered only afterwards. Presented in comprehensible professional language, with the object and the concrete effect, not as a technical parameter that only a developer can read. Decided independently of the AI client in use, so that changing the client does not drag the control away with it. And executed exclusively on a state that was checked once more immediately before execution.

A tool such as Docker MCP Enterprise Gateway is therefore not a building block that could simply be fitted in for Jira approvals — it is a competitor with a different functional cut and a different target picture, not a missing piece of the puzzle in JiCo's own system.

An examination that does not stay a one-off

This kind of examination is not a one-off exercise to be ticked off and then forgotten. The market for tools around AI security moves fast, and a vendor that does not close a particular gap today may well have closed it in half a year. The right attitude is therefore not to examine a list of competitors and building blocks once and then regard that list as valid for all time, but a willingness to ask the same question again at regular intervals — and to admit honestly when an earlier assessment turns out to be out of date.

Anyone who commits to a public statement about the competition once and then never checks it again risks exactly what had to be corrected here: a sentence that was true at the moment of writing and no longer true a year later. The lesson from it is less that one has to get everything right the first time — that rarely succeeds completely — than that one has to be willing to correct a statement that has become wrong just as publicly as it was originally made.

The lesson that reaches beyond this one case

An in-house build that sells itself with "nobody else can do this" holds only until somebody shows the opposite — and in a fast-moving market that is a question of months, not years. An in-house build that instead names concretely which two tools were examined and at which exact point they demonstrably stop holds considerably longer. It even holds when a third tool eventually appears that can do more than the first two — because then the new situation can simply be checked again and the sentence corrected once more if need be, exactly as the first time.