allod/strategy
2
0
Fork 0
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions

Explore explicit declarative agent capabilities #14

New issue
Open
opened 2026-07-10 23:50:38 +01:00 by allod-agent · 0 comments
allod-agent commented 2026-07-10 23:50:38 +01:00
Member
Copy link

User story: So that I can review an agent's authority before a session starts, Allod needs an explicit capability model that can be generated, enforced, and audited across repos, network, and service access.

Part of the "Agent isolation & security boundary" arc.

Context

Allod already has several authority signals, but they are spread across different layers: inventory repo lists, Forgejo user permissions, git policy files, VM closure boundaries, public/private repo splits, and human-only gates for host-side operations. That works, but it still leaves much of an agent's authority implicit in where the session happens to run and which credentials or checkouts happen to be present.

This issue is inspired by two comparison points:

Netclode is useful because it treats session authority as something that can vary by repository, write access, network access, and service integration. Allod is different: it is built around declarative NixOS architecture, public/private repo boundaries, and long-lived VM profiles. The design question is how to make Allod's authority model explicit and enforceable without losing the benefits of declarative system configuration.

Goal

Explore a capability model that describes what an agent may access or modify before the session starts. This could eventually cover repositories, remotes, network ranges, Forgejo operations, credential-mediated services, host commands, VM lifecycle actions, writable paths, or other resources. The point is to replace implicit trust with declared authority boundaries that can be reviewed, generated, enforced, and audited.

Questions to explore

  • What is the right unit of authority in Allod: VM profile, agent session, repository, task, Forgejo identity, or some combination?
  • Which existing declarations already behave like capabilities, and which are only convention?
  • Should capabilities live in inventory, secrets, strategy, profiles, or a separate policy layer?
  • How should a capability declaration map to enforcement points such as Forgejo permissions, SSH keys, git hooks, network policy, proxy authorization, filesystem mounts, or human gates?
  • Can a proposed capability set be diffed and reviewed like other NixOS configuration before an agent session receives it?
  • How should temporary capability escalation work when an agent discovers it lacks access needed for the task?

Non-goals for now

  • Designing a complete policy language.
  • Selecting a sandbox, network, credential, or control-plane implementation.
  • Collapsing all authority into a single mechanism.
  • Copying Netclode's session model directly; it is provenance and contrast, not a target blueprint.
**User story:** So that I can review an agent's authority before a session starts, Allod needs an explicit capability model that can be generated, enforced, and audited across repos, network, and service access. _Part of the "Agent isolation & security boundary" arc._ --- ## Context Allod already has several authority signals, but they are spread across different layers: inventory repo lists, Forgejo user permissions, git policy files, VM closure boundaries, public/private repo splits, and human-only gates for host-side operations. That works, but it still leaves much of an agent's authority implicit in where the session happens to run and which credentials or checkouts happen to be present. This issue is inspired by two comparison points: - Netclode: https://github.com/angristan/netclode - Netclode network access notes: https://github.com/angristan/netclode/blob/master/docs/network-access.md - Netclode self-hosted coding-agent article: https://stanislas.blog/2026/02/netclode-self-hosted-cloud-coding-agent/ - microvm.nix: https://github.com/microvm-nix/microvm.nix - Michael Stapelberg's coding-agent MicroVM setup: https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-microvm-nix/ Netclode is useful because it treats session authority as something that can vary by repository, write access, network access, and service integration. Allod is different: it is built around declarative NixOS architecture, public/private repo boundaries, and long-lived VM profiles. The design question is how to make Allod's authority model explicit and enforceable without losing the benefits of declarative system configuration. ## Goal Explore a capability model that describes what an agent may access or modify before the session starts. This could eventually cover repositories, remotes, network ranges, Forgejo operations, credential-mediated services, host commands, VM lifecycle actions, writable paths, or other resources. The point is to replace implicit trust with declared authority boundaries that can be reviewed, generated, enforced, and audited. ## Questions to explore - What is the right unit of authority in Allod: VM profile, agent session, repository, task, Forgejo identity, or some combination? - Which existing declarations already behave like capabilities, and which are only convention? - Should capabilities live in inventory, secrets, strategy, profiles, or a separate policy layer? - How should a capability declaration map to enforcement points such as Forgejo permissions, SSH keys, git hooks, network policy, proxy authorization, filesystem mounts, or human gates? - Can a proposed capability set be diffed and reviewed like other NixOS configuration before an agent session receives it? - How should temporary capability escalation work when an agent discovers it lacks access needed for the task? ## Non-goals for now - Designing a complete policy language. - Selecting a sandbox, network, credential, or control-plane implementation. - Collapsing all authority into a single mechanism. - Copying Netclode's session model directly; it is provenance and contrast, not a target blueprint.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
agent/derived-platform-docs
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/strategy#14
No description provided.