The one emergency exit

The temptation to do it directly, "just quickly"

Every security design has a weak point, and most of the time it is not the technology but the shortcut somebody takes because it happens to be more convenient. With a system like JiCo that shortcut would be easy to take: a curl command straight against the Jira API, a second API token sitting next to JiCo in some other tool, a script that reaches past the gate "just this once" because it is quicker that way.

What makes such shortcuts treacherous is that they look harmless in the moment. Nobody copying a token is thinking about the fact that they are disabling two fundamental protections at the same time — the redaction of personal data before the model, and the human approval before any change. A direct path around JiCo to Jira makes both gates useless, in one stroke, without anyone ever having taken that as a deliberate decision.

Using the terminal is welcome — the only question is where it points

That does not mean JiCo forbids the terminal or eyes it with suspicion. Quite the opposite: anyone who would rather type a command than trigger it through a chat dialogue should be able to do so — for many experienced users that is in fact the more natural and faster route. The question is not whether a terminal command is executed. The question is where that command points.

And here lies the actual trick: the curl command JiCo will print for an approval does not point at Jira. It points at JiCo itself, secured with a one-time token that is valid for precisely this one action and expires afterwards. JiCo then carries the action out exactly as it would have been carried out had it been confirmed through the interface: checked, recorded, and only against the current state of the ticket, read once more just beforehand. The convenience of the terminal is preserved. Both gates are preserved as well. Nobody has to choose between the two. This terminal route is decided but not yet built; today you approve in the panel or with jico approvals.

The one route that really is direct — and why it exists all the same

A second route is planned that genuinely goes straight to Jira, unprotected: the raw export, likewise decided but not yet built. Unlike the accidental shortcut above, this is neither an oversight nor a secret, but the one explicitly named and marked emergency exit in the whole system. It exists because there are real situations in which somebody needs a complete, unfiltered data export — for an external audit, say, or a migration where the usual gates are simply not the right tool.

Three things separate this emergency exit from a silent bypass: it is used only on an explicit, deliberate request, never automatically and never as a default. It comes without the guarantees of the two gates — anyone using it knows that they are leaving them behind. And the export itself is recorded in the audit trail, so that nobody can later be surprised that it took place.

The difference between this marked emergency exit and quietly bypassing the gates is not a technical one but a matter of honesty: a boundary that is openly named as a boundary can be defended later — to an auditor, to a data protection officer, to oneself. A boundary that disappears into the small print, or is not documented at all, turns into an accusation eventually, usually at the least comfortable moment.

A pattern that reaches beyond JiCo

Anyone who has worked in an IT department knows the basic pattern of this problem from outside JiCo as well: it is the same dynamic that arises wherever an official, controlled solution exists while a more convenient, less controlled route remains technically possible. Shadow IT almost never comes from bad intent — it comes from someone under time pressure taking the route with the least friction at that moment, without thinking the consequence through to the end.

The only effective lever against this pattern is rarely an additional rule of prohibition, which nobody reads before breaking it anyway. It consists in making the controlled route so convenient that the shortcut loses its actual advantage. That is exactly what the terminal route through JiCo tries to achieve: anyone who prefers typing to clicking should not have to take a detour through a second, unprotected connection — the convenient route and the controlled route should as far as possible be the same route.

Where the boundary really runs — and where it deliberately does not

Thought through to the end, the less comfortable truth belongs here too: a second, personal Jira access alongside JiCo — an API token somebody enters into another tool because it seems practical at the time — reads past JiCo. For the reading path alone, that cannot be prevented technically by JiCo's own means. It is a question of how the working environment is set up in the company, not a question of the tool's architecture — comparable to a door lock that is of no use if somebody leaves a window open next to it.

The writing path is not affected by this, and that is the decisive difference. Without the route through JiCo there is no approval gate to pass, and without an approval nobody writes — no second access can circumvent this mechanism either, because it never comes into contact with it in the first place.

This boundary stands here deliberately in the running text, not as a footnote in the small print. A product that claimed to prevent every conceivable outflow of data would be refuted the moment somebody in the company sets up a second, unprotected access — and a resourceful auditor would find that contradiction in ten minutes. JiCo therefore does not claim it. It makes the route through JiCo the more convenient, safer, better documented route — not the only technically possible one. The difference between those two promises is small in wording and large in credibility.