Agent-Native OS Design: Isolation, Permissions, and Audit Trails for Anolis OS 27

The Claim Behind Anolis OS 27's Agent-Native Design

An operating system whose default principal isn't a logged-in human is a different kind of announcement than a new compiler flag. Pandaily reported on 24 October 2026 that OpenAnolis is building Anolis OS 27 around agents, and in the same report Alibaba Cloud claimed agents now write 95% of new code. Those statements belong together: one describes infrastructure, the other workload volume. This post examines what an agent-native OS actually has to provide — per-task isolation, capability-scoped permissions, and audit trails that attribute actions to a model version — and what to verify once OpenAnolis publishes technical details.

Isolation, permissions, and audit trails are the load-bearing parts of that design. None of them fall out of attaching an AI assistant to a Linux distribution built for people. An assistant that writes suggestions while sudo still grants root is an AI-assisted OS. An agent-native OS has to answer questions POSIX never asked: who authorized this action, which model version produced it, and what the blast radius is when the agent is wrong or manipulated.

What Is Confirmed About Anolis OS 27, and What Is Still a Claim

Why Agent-Native Is a Different Target Than AI-Assisted

In the AI-assisted model, a human edits a file, an assistant suggests a line, and the human's UNIX identity owns every permission check downstream. The security model survives because there is always a human at the end of the chain to blame and to authenticate.

In the agent-native model, the unit of authorship is a process that generates and executes code in a loop. That process calls tools, reads files, runs builds, and commits, often without a human reading the intermediate steps. The account model stops being a useful abstraction at exactly that point.

The honest counterpoint matters here: the 95% figure, if accurate, describes code volume, not code review. High volume of generated code with a human review gate is a tooling problem. High volume without a review gate is an authority problem. Volume alone does not justify redesigning a kernel surface. The justification is that the decisions are being made by something with no stable identity and no reliable judgment.

The human-user assumptions baked into POSIX permissions

Ambient authority is the core issue. A UNIX account is a long-lived principal; everything that account spawns inherits its full rights until the process exits. sudo is all-or-nothing: you either have the ability to execute as root or you do not, and there is no meaningful "run make as root but not systemctl" primitive. Environment variables and home-directory dotfiles — .npmrc, .gitconfig, .aws/credentials, GITHUB_TOKEN — leak into anything the process spawns. File ownership is a coarse proxy for intent: chmod 600 says nothing about whether the read was authorized for this task.

An agent that can write its own scripts turns every one of those into a privilege-escalation path, because generated code inherits whatever the parent process holds. A model that reads a hostile README and then writes a "helper script" is not exploiting a bug; it is using the permission model as designed.

What changes when the author is a model

The principal becomes ephemeral and probabilistic. The same input can produce different code on a different day. The artifact's provenance is a prompt plus a model version rather than a developer's keystroke, and no part of that is representable in a traditional Unix audit record.

That shift is what forces capability-scoped grants and per-action audit records. Sandboxing alone does not fix it. A perfect sandbox that still hands the agent a repo-wide push token has contained the problem inside a very fast, very committed boundary.

Isolation — Per-Agent Runtime Boundaries, Not Per-User Ones

The boundary should be per task, not per account. A credible isolation story needs four properties:

• a disposable execution context created per task and destroyed after it
• no shared writable filesystem by default — an explicit mount if the agent needs one
• network denied unless the task's grant says otherwise
• resource ceilings so a runaway loop cannot starve the host

All four are buildable with primitives that ship today. This is the shape a platform would have to automate:

# Disposable namespace + cgroup budget around a single agent task.
## Lab illustration only -- see the warning below.

systemd-run --user --scope -p MemoryMax=512M -p CPUQuota=50% -p TasksMax=64 unshare --user --map-root-user         --mount --pid --fork         --net --uts --ipc bash -c 'mount -t tmpfs tmpfs /tmp && cd /workspace/repo && node /task/entry.js'

The --net flag is the interesting one. A fresh network namespace gives the child a down loopback interface and nothing else, so egress fails without any firewall rule:

$ unshare --user --map-root-user --net --fork \
    node -e 'fetch("https://1.1.1.1").then(r=>console.log(r.status)).catch(e=>console.log("ERR", e.cause?.code ?? e.message))'
ERR ENETUNREACH

The exact errno depends on how the host resolves names. A hostname lookup in the same sandbox typically surfaces EAI_AGAIN instead, because the resolver is unreachable rather than the route being absent. Either way, the default flips from allow to deny, which is the whole point.

Blast radius as the design metric

The useful security question for an agent-native platform is not "is the agent sandboxed" but "what can this agent touch in one task?" That is measurable, and it belongs in the manifest:

The gap between the first two rows is not a sandbox setting. It is the difference between a contained failure and an incident, and it exists purely because of what credential the task was handed.

Permissions — Capability Grants Instead of Ambient Authority

Agents reintroduce a classic confused-deputy problem. A tool-call layer that holds broad credentials will act on any instruction that reaches the model, and the model cannot reliably distinguish an instruction from a user from an instruction embedded in a file it was asked to summarize. The deputy is confused the moment hostile content arrives.

The fix is the same fix that worked for cloud IAM: short-lived, narrowly scoped grants bound to a specific task. Express the policy declaratively so it can be reviewed and diffed.

task: build-agent-7f3a
agent: ci-build-agent
model:
name: coding-agent
version: "2026-10-01"
grant:
expires: 2026-10-24T02:37:08Z     # 30 minutes, not renewable per-task
filesystem:
  read:  ["/workspace/repo/**"]
  write: ["/workspace/repo/out/**"]
network:
  egress: []                       # deny by default
tools:
  shell:
    allow: ["npm ci", "npm run build", "npm test"]
  git:
    allow: ["diff", "status", "log"]
    deny:  ["push", "tag", "force-push"]
approvals:
  - action: "git push"
    approver: human
    reason: "publishes to a shared branch; irreversible"

Scoped cloud tokens and OIDC workload identity are standard today. This is not novel cryptography. What is genuinely new is binding the grant to a specific agent task and a specific model version, so the credential is meaningless once the task ends and the audit record can name what produced the action. The expiry in the example is deliberate: a grant that outlives its task is ambient authority with extra steps.

What developers should demand from an agent-native platform

1. Deny-by-default capabilities. No filesystem, network, or tool access unless the grant says so explicitly.
2. Per-task credential issuance. A credential that outlives the task is a leak waiting for a log line.
3. An approval gate for irreversible actions. Push, delete, deploy, and payment verbs require a named human.
4. A machine-readable manifest per agent. If you cannot diff what an agent is allowed to do, you cannot review a change to it.

Prescriptive, not aspirational: if a platform cannot produce the manifest in item four, it has not implemented permissions. It has implemented a UI.

Audit Trails — Attribution When the Author Is a Model

Audit is the hardest of the three because "who did this" has no single answer. The agent did it, the model produced it, the prompt shaped it, and the human approved it — or did not.

A minimum record per action needs: task ID, agent identity, model name and version, a prompt hash, the tool calls made, the command or diff executed, and the approving human if any.

{
  "seq": 1841,
  "prev_hash": "sha256:6f1c2a...",
  "hash": "sha256:9ab04d...",
  "ts": "2026-10-24T02:11:47.913Z",
  "task_id": "build-agent-7f3a",
  "agent_id": "ci-build-agent@lab",
  "model": { "name": "coding-agent", "version": "2026-10-01" },
  "prompt_hash": "sha256:3d7e91...",
  "action": { "type": "exec", "cmd": "npm run build", "cwd": "/workspace/repo" },
  "result": { "exit_code": 0, "duration_ms": 41234 },
  "diff": "sha256:be2155... (+14 -2 across 3 files)",
  "approved_by": null
}

Stock Linux tooling covers part of this and misses the rest:

Tamper evidence beats log volume

A log that can be edited by the same account that produced it is a debugging aid, not an audit trail. Append-only records with hash chaining — each entry committing to the previous one — give you something better than volume: the ability to say a record was not retroactively altered. Tie retention to the artifact rather than a 30-day window, so a shipped binary can be traced back to the agent run that built it.

Inference, clearly marked: no public Anolis OS 27 design document confirms a hash-chained audit schema. This is what the requirement implies, not what OpenAnolis has stated.

What to Watch as Anolis OS 27 Details Emerge

Four signals would confirm the agent-native framing is substantive rather than branding:

• A published isolation mechanism. If it is per-task namespaces plus cgroups, adoption is incremental and your existing containers get you most of the way. If it is a new kernel primitive, budget for a slower migration.
• A permissions model that differs from ordinary Linux accounts. If agents are still just users with sudo, nothing has changed and the framing is cosmetic.
• A documented audit schema. Without one, you build your own and port it later.
• Review or test data behind the 95% figure. If the number holds up under scrutiny, agent-written code is the default and review tooling becomes the bottleneck. If it does not, the timeline for the whole redesign loosens considerably.

Conclusion

The interesting claim is not that agents write code. It is that an operating system would treat them as first-class principals — with their own isolation boundary, scoped grants, and audit records. That is a real architectural statement, and it is worth watching precisely because it is hard.

Until the isolation, permission, and audit specifics for Anolis OS 27 are public, teams should build the capability-scoped, per-task-audited pattern themselves. It is required regardless of which distribution wins, because the failure mode it prevents is already reachable on the OS you are running today.

Further Reading

• Pandaily: OpenAnolis Builds Anolis OS 27 Agent-Native as Alibaba Cloud Says Agents Write 95% of New Code — the source report, published 24 October 2026
• OpenAnolis community site — upstream project announcements and release notes
• Linux man-pages: user_namespaces(7) — the isolation primitive used in the lab snippet
• Linux man-pages: unshare(1) — flags referenced above
• Kernel documentation: Control Group v2 — MemoryMax, CPUQuota, and TasksMax semantics
• Linux man-pages: seccomp(2) — the syscall filtering layer the lab snippet deliberately omits