Skip to content
Plexify
Language: en

From the assessments3 min read

No log, no key

An agent you have to watch all the time is not automation. Three places where we moved control out of the instruction and into the construction.


by Maik Tran

You can tell an agent what not to do. Or you can build it so it cannot. The first is a request, the second is construction. We do not rely on requests.

Runtimes for coding agents are a mass market: one open-source project of this kind has over 40,000 GitHub stars. They solve keeping agents running in the background. What an agent is allowed to do is a different question, and it does not answer itself.

Haki Dock runs coding agents locally, each in its own sandbox with its own working directory. Three places where the control sits in the construction and not in the prompt.

The network: what is not allowed has no counterpart

The agent's network traffic goes through a proxy whose rules are generated fresh for every run: one entry per permitted destination. At the end of the list sits a chain that points at nothing. A connection that matches no rule fails, and there is nothing an agent could negotiate with. If the proxy is down, the agent does not start at all.

The key: no log, no key

An agent needs an API key to work. It sits in the operating system's vault (Keychain on macOS, DPAPI on Windows, an encrypted file on Linux), not in the project and not in the prompt. Before it is released, the system records who asked for it and for what. If recording fails, nobody gets the key.

Inside the sandbox it then lies as a file in memory, and the environment variable holds only the path to it. While the sandbox runs, the agent can therefore read it. Hiding that would be dishonest. That is why the network sits in front of it: it can only send the key to destinations on the list.

The approval: a button that must not lie

The first version of our approval step showed the person approving what the agent had written about its own work. That is the agent's word about itself, not a control.

Today, above “Approve” and “Reject”, sits the evidence: which files changed and the diff itself, compared against the start of the task and not against the last run. Because at approval the question is not what the last run did, but what enters the world if I agree.

One small detail in the code shows what this is about. When git cannot answer, the interface does not show an empty diff, it says it does not know. An empty diff reads as “nothing changed”, and that is the one lie that makes an approval worthless. A gate that says “nothing” when it does not know is theatre.

Whoever approves is liable. A button that knows nothing makes that person liable for something they could not see.

What is still missing

Haki Dock is in development. Three things we do not want to skip over:

  • The evidence is computed on the machine where the agent works. Someone reviewing from another machine cannot see it yet.
  • Two interfaces to the server are not connected yet, including the central record of the approval decision.
  • The delivery path for signed updates is still open.

We do not rely on an agent keeping to the rules. We build the rules into what it can touch.

agents in the house, but nobody knows what they may do?

We look at what your agents can and cannot do today, even when the answer is uncomfortable. I will get back to you within 24 hours.

Maik Tran
Maik Tran

By sending this you agree that we may process your details in order to handle the enquiry. Details in the privacy policy.

back to Insights