An Agent That Can Edit Its Own Autonomy Ceiling Has No Ceiling

An agent that can write to its own configuration file can edit the rules it is operating under. That is not a governance problem waiting to happen. It already happened the moment you deployed it.

This came up directly while building an AI employee product. Each customer’s agent instance is configured by a YAML file: which connectors are active, which skills are enabled, what trust ceilings apply to which action categories. For a period, the agent process had write access to that file. Not because we intended it to - because we hadn’t explicitly taken that access away. The default posture of most container environments is broad write access within the working directory, and config files tend to live there.

The fix was two lines in a Dockerfile: chown 0:0 and chmod 0600 on the governance artifacts directory and everything inside it. The agent runs as a non-root user. The OS now rejects any write attempt on those files - not because the agent has been instructed not to modify them, but because the agent physically cannot.

That distinction is the entire point.

Why Prompt Instructions Are Not a Security Boundary

A system prompt that says “do not modify your configuration file” is an advisory. It works under normal conditions. It fails under exactly the conditions where you need it most.

Consider the failure modes. An adversarial user sends the agent a crafted input that includes a plausible-sounding reason why the configuration needs updating right now - a connector is broken, a skill ceiling is causing an error, the YAML is out of sync. The agent has seen millions of examples of autonomous systems modifying their own config as a normal remediation step. The instruction not to do it is one token weight among many, competing against a context window full of reasoning that points toward modification.

Or consider hallucination. The agent doesn’t need to be manipulated. It can reason itself into an exception. A sufficiently complex task can produce a chain of inference that concludes modifying the governance file is the correct next step - and from inside that reasoning chain, the conclusion looks sound. The agent is not lying. It is wrong. And there is no mechanical check that catches the error before the write happens.

Prompt-level constraints are best-effort. They degrade under adversarial pressure and under complexity. For anything that touches the agent’s own operating envelope, best-effort is not acceptable.

What Filesystem Ownership Actually Enforces

When the config file is owned by root with 0600 permissions and the agent runs as UID 1000, the kernel’s permission check happens before any agent-level code runs. There is no try/catch the agent can write. There is no system prompt override. There is no reasoning path that leads to a successful write. The syscall returns EACCES and that is the end of the story.

The agent can still read the file. It loads its own configuration at startup, knows what connectors are active, knows its trust ceilings. Read access is intentional - the agent needs to know its own parameters. Write access is gone, and gone at a layer the agent cannot reach.

The governance artifacts directory gets the same treatment. Any file in that directory that declares what the agent is and is not allowed to do is owned by root. The agent process cannot create new files there, cannot modify existing ones, cannot delete anything. What was written during provisioning stays exactly as written until a human or a separate privileged process changes it.

This is what an earlier piece we published on harness architecture pointed at when it identified autonomy configuration living outside the agent’s reach as a known gap. Here is the concrete form that principle takes: chown -R 0:0 /app/governance && chmod -R 0600 /app/governance.

What Else Follows From This Principle

The same reasoning applies to audit logs. If the agent can write to the audit log, it can also overwrite or truncate it. An audit log the agent controls is not an audit log - it is a record the agent could edit to hide its own actions. Audit streams should be append-only from the agent’s perspective, written to a destination the agent can push to but never modify. Object storage with write-once semantics, or a log aggregation endpoint that rejects anything other than new entries.

Configuration portals - the interfaces through which a human administrator changes what a customer’s agent is allowed to do - must run as separate processes with separate credentials. The agent can expose a read endpoint so an administrator can inspect current settings. The write path that actually updates the YAML must be a different process entirely, authenticated separately, never reachable from within the agent’s execution context. The agent can surface “here is my current configuration” all day. The agent cannot submit “here is my updated configuration.”

The test for whether governance is real is one question: can the agent, under any circumstances, change the rule it is operating under? If the answer is yes - through any path, prompt injection, hallucination, or direct write - then the rule is advisory, not governance. Advisory rules are better than nothing. They are not a security boundary.

Provisioning Is the Moment of Control

The enforcement window for all of this is provisioning. When a new agent instance starts up for a customer, the governance artifacts are written by a privileged setup process, the file ownership is changed to root, and from that point forward the agent is a read-only consumer of its own constraints.

This means the design of the provisioning step matters as much as the design of the agent itself. Who can trigger provisioning? What validates the YAML before it is written? What audit trail covers the provisioning event? These are not runtime agent questions - they are infrastructure questions, answered before the agent process ever starts.

An agent that launches with correct governance artifacts and cannot modify them is, in a meaningful sense, bounded. Not perfectly - runtime behavior still matters, and connectors can still be misused within their allowed scope. But the constraint itself is load-bearing. It will hold under pressure. That is a different class of system than one where the constraints are stored in the agent’s context window and survive only as long as the agent’s next inference agrees with them.

Build the harness so the agent cannot modify its own cage. Then the cage is real.