Adopting a vendor agent harness with its dangerous defaults enforced off

Decision records, nine of ten. One architecture decision per piece, from a governed AI-agent platform I designed and built as a prototype for Dutch local government.

The situation

A vendor’s agent harness, the runtime loop that takes a model, a tool set and a session and turns them into an agent, had been refused for the platform while it was prerelease. Reasonable: the platform does not take dependencies on things that can change shape overnight. Then it reached a stable release, and the refusal lapsed on its own terms.

The case for adopting it was strong. Building and maintaining the rebuild loop, session handling and human-in-the-loop plumbing in-house is months of work that does not differentiate anything.

The case against was specific. Four capabilities ship on by default, and each breaks a rule the platform already enforces. Hosted web search: ungoverned egress, the model reaching the internet outside the retrieval routing control. File access: unsandboxed reads and writes on the host, outside isolation. File-based memory: the harness remembering things in files the kernel does not see, bypassing the memory promotion path. And heuristic tool auto-approval: the harness deciding on its own that a tool call looks safe enough to skip asking, which is a model-adjacent component approving an action.

Any one of those on, and the platform’s guarantees are false.

The decision

Adopt the harness. Enforce all four capabilities off, at two points, both fail-closed.

The first point is the agent host. When it starts a harness, it checks the capability state. If any of the four is on, or its state cannot be determined, the host refuses to start. Not a warning, a refusal.

The second point is admission. Any package that declares it uses the harness must also declare the state of the four capabilities. A package that uses the harness and does not declare is refused. An unstated declaration is treated as a failure, not as a default.

The check is expressed as capability state, not as raw configuration flags. The question the gate asks is “is hosted web search off”, not “is flag X set to false”. That matters because the vendor can rename flags, invert their polarity, or move them between versions, and a gate written against flag names would silently stop checking the right thing. There is a test that the gate’s polarity cannot be inverted: a fixture with the capability on must be refused, and a fixture with it off must pass, in every version the platform pins.

Hofstadter’s law says everything takes longer than you expect, even when you account for Hofstadter’s law. The security version: every default is on, even the ones you remember turning off, after the upgrade.

What I rejected, and why

Permanent refusal. Keep building the loop, the session model and the human-in-the-loop plumbing in-house. I had done enough of that to know the cost, and it was not buying any governance property the capability gate did not buy more cheaply.

Deferring. Adopt it later, when the defaults change or the platform is more mature. The defaults were not going to change in the platform’s favour, and deferral means the next person to need a harness picks one without the gate.

Relying on configuration discipline. Turn the four off in the deployment config and trust that nobody turns them back on. A security property must not depend on someone remembering. And vendor upgrades change defaults silently; a minor version bump can turn a capability back on in a config that was correct last week. The gate has to re-check every start, every admission.

What it costs

The gate must assert “known and off”, not “not seen on”. That is a stricter check and it means the gate has to understand the harness’s capability model well enough to query it positively. Every version re-pin requires re-verifying that the query still means what it meant.

A declaration duty on package authors, which is paperwork, and paperwork gets resented. Here is the anecdote. On the day I drafted the admission rule, I wrote it so that every package had to declare harness capability state. That over-scoped it: a package with no agent in it at all, a pure tool server, was now being refused for failing to declare something it could not possibly have. Corrected the same day, to packages that declare harness use. It is a small error and I mention it because this is exactly the kind of rule that gets written too wide, and the symptom is not a security hole but a wall of refusals that teaches people to work around the gate.

What it does not do

It does not govern what the harness does with the capabilities that remain on. The rebuild loop, the session model and the tool-call plumbing are vendor code running inside the platform’s isolation boundary, and the gate says nothing about them. They are covered, to the extent they are covered, by the fixed set of kernel controls.

The host-side check was built. The admission-side check was specified and partly built. The polarity test exists for the pinned version only.

If you take one thing

List the capabilities your agent runtime ships with on by default. For each one, say which of your rules it would break if it were on. Then check whether anything other than a config file is keeping it off.

Reversing the polarity solved most problems on Doctor Who. A test that the polarity of four flags can never be inverted solves a quieter one.

References

The allusions and quotations in this piece, with their origin:

• Douglas Hofstadter, Gödel, Escher, Bach (1979): Hofstadter’s law.
• Doctor Who, the Third Doctor era (1970s): “reverse the polarity”, the recurring fix.