The order decides

A Friday afternoon, a ticket, one click too many

Picture the scene that is playing out in a thousand IT departments right now: somebody has connected Claude or another language model to an MCP tool that can read Jira. It is convenient — you type a question, the model fetches the ticket, summarises it, suggests a reply. Nobody has bad intentions. Nobody has spent even a minute thinking about what is actually written in that ticket.

What is written in it is usually harmless. Sometimes, though, it holds the name of a colleague who was on sick leave. A telephone number in the comment history. An insurance number somebody copied into a free-text field by mistake instead of entering it into the system intended for it. None of it was meant for a language model — and yet it ends up there as soon as the ticket goes to the API as text.

The real question is not whether this happens. It happens. The question is: where does the protective layer take effect — before or after?

Filtering downstream protects nothing that is already gone

Most solutions sold today as "AI security" filter the answer. The model receives the full text, processes it, and only at the end is it checked whether anything conspicuous appears in the output that ought to be cut out. That sounds like a security measure. It is not one.

The reason is simple and cannot be argued away: once the text has been in the model context, it has been there. With a cloud model that means, concretely: the data has left the building — it has travelled over another provider's line, possibly been logged, possibly been used for training, depending on what the contract with the provider allows. A filter that removes something from the visible answer afterwards changes none of that. It polishes the result, not the event.

It is the same mistake as locking a door only after the burglar has already been inside and left again. The door is shut. It did no good.

That is why one single, non-negotiable principle applies at JiCo: redaction happens before the model, never afterwards. Names, contact details, insurance numbers and similar patterns are replaced by placeholders before the text leaves the local program at all. The model sees «Person 1» instead of a name — and can still work sensibly, because the placeholder stays consistent for as long as the session runs. This is not a setting that can be flipped when needed. It is the order in which the building blocks are assembled — and an order cannot be forgotten by accident.

An assistant that may write is an assistant that can get something wrong

The second blind spot concerns not reading but writing. An AI assistant that may comment on a ticket, change a status or set a field does in fact save time — until the day it gets something wrong. A status that jumps to "done" too early. A comment that phrases a supposition as a fact. A field that is overwritten because the model understood an instruction differently from how it was meant.

The annoying part is not even the mistake itself — people make mistakes too. The annoying part is the question nobody can answer afterwards: who actually decided this? A tool that writes autonomously leaves no decision behind, only an execution.

JiCo turns that around: every changing action is held and presented to a person — the command in professional language, the ticket concerned, the concrete effect, before anything happens. And the rule is deliberately phrased strictly: a tool whose classification JiCo does not know for certain counts as writing, not as harmless. In case of doubt, it is held. This attitude — unknown means writing, not "it will probably be fine" — is precisely the kind of caution that is otherwise readily sacrificed to convenience in software development.

Yesterday's approval does not apply to today's ticket

The third point is the easiest to overlook, and for that very reason the most important. Between the moment a person sees a proposal and the moment they actually approve it, time passes — minutes, sometimes hours, when the approval folder is only reviewed the next morning. During that time the ticket lives on. A colleague comments on it. An automatic workflow changes a field. The basis on which the approval actually rested no longer exists in that form.

JiCo therefore reads the actual state of the object once more, immediately before execution. If something has been changed or commented on, it is not executed — the action moves to a follow-up list with a reason, for renewed consideration. And the rule is deliberately stricter than it would have to be: even a change to a field that has nothing at all to do with the actual action blocks it. That occasionally costs a superfluous query. The price for it is that nothing is ever executed against a state that no person has seen any more.

Three rules that only take effect together

The real point about these three principles is that none of them would suffice on its own — they interlock, and it is exactly that which makes the combination robust against the cases in which a single principle reaches its limit. Redaction before the model alone would be of no use if an assistant were still free to write — one would then know what the model had seen, but no longer what it had done afterwards. An approval requirement alone would be of no use if names and contact details had long since landed unredacted in the model context before any proposal to decide on even arose. And a state check alone would be of no use if neither the data had been protected nor the action held.

Only together do the three rules form a chain that holds at every point: what the model sees is already protected. What is to be changed is always presented to a person. And what is finally executed is guaranteed to rest on the state that this person actually saw, not on one that has meanwhile gone stale again. Take one of the three rules away and it is not only that one rule that breaks — the effect of the other two is undermined as well, because they build on one another instead of standing independently side by side.

What this order costs — and what it is worth

Honesty belongs to this principle, not merely as a footnote: this order makes the work slower. An assistant that reads freely and writes freely is faster — until the day somebody asks what it actually saw and what it did, and nobody can give a reliable answer.

JiCo is built for exactly that day. Not for the smooth normal case, but for the moment when an audit, a data protection officer or a customer asks — and the answer is not "we believe so", but a piece of evidence.