If you were on call over Labor Day weekend — and somebody was, somebody always is — the containers your services ran inside were enforcing a permission model built for a world where "user" meant a person sitting at a terminal in a university computing lab. I was that person for a few years, holding root on every machine in the building, back before anyone had thought to stop a teenager from having it. The model is fifty-two years old. It has mostly held.
Ken Thompson and Dennis Ritchie's Unix, circa 1974, had a login sequence that asked for a name and a password, set the process's user ID to "that of the person logging in," and started a shell. Files recorded their owner's UID. A handful of permission bits governed who could read, write, or execute — owner and everyone else. (The familiar owner/group/other layout arrived slightly later, but the principle didn't change: a few bits per file, checked against the caller's identity.) One super-user ID skipped the checks entirely. That was the protection model.
The simplification was deliberate, and both authors knew exactly what they were simplifying away. Thompson and Ritchie had worked on Multics, which maintained per-principal access-control lists on every protected object, with wildcard matching and ordering rules. Ritchie later described Unix as a reaction to Multics's appetite for resources: keep the hierarchical filesystem, keep the shell, simplify or discard much of the rest. Protection was one of the things that got simpler. Coarse, fast, and resting on one assumption: the system knows who you are because you logged in, and you are a person.
That assumption came through to us almost intact. Linux user namespaces, the mechanism underneath container isolation, virtualize UIDs so a process can appear as root inside its container while holding an unprivileged UID on the host. But when that process opens a file, the kernel maps the namespace UID back to the host UID and runs the same check Thompson and Ritchie would recognize on sight. When an orchestrator launches a workload, it assigns a service account that maps to a UID — the same identity-binding that login used to perform, minus the person and the password. Cgroups cap resources. Seccomp filters restrict system calls. Containers bundle several isolation mechanisms together, but the authorization question at the bottom of the stack is still: given the credential on this process, may it perform this operation on this object?
When the process represents a person, or a service with a fixed and known job, that question is sufficient. The UID says what the process may touch. The bits say how.
Now put an autonomous agent in the container. The agent holds credentials — a service account, a mapped UID — and the kernel will enforce what those credentials allow, faithfully and fast. What the kernel has no field for is whose errand this particular action serves. There is no representation of the specific instruction that justified it, no way to distinguish an action the agent was told to take from one it decided to take on its own. Identity belongs to the process. Authority belongs to the credential. But the mandate — the bounded, specific, expirable reason this action should be happening right now — was never in the model, because in 1974 the mandate was the person at the terminal. Their presence WAS the mandate. You didn't need to encode it, because you could go ask them.
I argued in an earlier piece that logs can't reconstruct authority that was never in the request to begin with. That holds a layer down too. A container will constrain where an agent process can reach. It has nothing to say about why.