Explore keeping secrets outside agent-controlled environments #13

New issue

Open

opened 2026-07-10 23:50:23 +01:00 by allod-agent · 0 comments

allod-agent commented

2026-07-10 23:50:23 +01:00

Member

User story: So that I can let agents use authorized services without handing them durable secrets, Allod needs an architecture path for brokering service access outside agent-controlled environments.

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

Context

Allod already reduces agent exposure by separating public template repos from private identity and credential repos, constraining the allod-dev VM to public checkouts, and treating host-side secret work as a human gate. That is a strong baseline, but agents still need to use external services, and the default way to do that is often to place a usable credential somewhere inside the agent-controlled environment.

This issue is primarily inspired by Netclode's secret-proxy architecture:

Netclode is useful here as a comparison point because its design keeps provider API keys outside the sandbox and mediates access through services outside the agent VM. This issue is not proposing that Allod copy Netclode's Kubernetes, MITM proxy, or service layout wholesale. The architectural goal is broader: agents should be able to use authorized services without possessing the underlying long-lived secrets.

Related comparison context:

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/

Those projects reinforce the value of isolating agent compute, but this issue is specifically about reducing secret material inside that compute boundary.

Goal

Explore an Allod architecture where a compromised agent VM has less durable credential material to steal or reuse. Agents may still need to trigger Git, Forgejo, model-provider, package-registry, deployment, or other service operations, but the long-lived credentials should ideally remain in a host-controlled, service-controlled, or otherwise narrower trust domain.

Questions to explore

Which credentials currently need to enter an agent-controlled VM, and which are only there because there is no brokered access path yet?
What should count as the secret boundary in Allod: the Nix store closure, the VM filesystem, process environment, Home Manager activation output, Forgejo identity, or a future host-side service?
Can Allod distinguish long-lived credentials from short-lived or session-scoped authority in a way that fits the existing NixOS and age/agenix model?
What audit signal would prove that a given service credential did not enter the agent environment, logs, shell history, or persistent workspace?
How should failures behave when a brokered service refuses a request: clear denial, human approval path, capability escalation request, or something else?

Non-goals for now

Choosing a concrete proxy, token exchange, socket, network, or control-plane implementation.
Replacing age/agenix or the existing private secrets authority.
Broadening what agents can do before the authority model is understood.
Treating Netclode's exact design as the target architecture.

**User story:** So that I can let agents use authorized services without handing them durable secrets, Allod needs an architecture path for brokering service access outside agent-controlled environments. _Part of the "Agent isolation & security boundary" arc._ --- ## Context Allod already reduces agent exposure by separating public template repos from private identity and credential repos, constraining the `allod-dev` VM to public checkouts, and treating host-side secret work as a human gate. That is a strong baseline, but agents still need to use external services, and the default way to do that is often to place a usable credential somewhere inside the agent-controlled environment. This issue is primarily inspired by Netclode's secret-proxy architecture: - https://github.com/angristan/netclode - https://github.com/angristan/netclode/blob/master/docs/secret-proxy.md - https://stanislas.blog/2026/02/netclode-self-hosted-cloud-coding-agent/ Netclode is useful here as a comparison point because its design keeps provider API keys outside the sandbox and mediates access through services outside the agent VM. This issue is not proposing that Allod copy Netclode's Kubernetes, MITM proxy, or service layout wholesale. The architectural goal is broader: agents should be able to use authorized services without possessing the underlying long-lived secrets. Related comparison context: - 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/ Those projects reinforce the value of isolating agent compute, but this issue is specifically about reducing secret material inside that compute boundary. ## Goal Explore an Allod architecture where a compromised agent VM has less durable credential material to steal or reuse. Agents may still need to trigger Git, Forgejo, model-provider, package-registry, deployment, or other service operations, but the long-lived credentials should ideally remain in a host-controlled, service-controlled, or otherwise narrower trust domain. ## Questions to explore - Which credentials currently need to enter an agent-controlled VM, and which are only there because there is no brokered access path yet? - What should count as the secret boundary in Allod: the Nix store closure, the VM filesystem, process environment, Home Manager activation output, Forgejo identity, or a future host-side service? - Can Allod distinguish long-lived credentials from short-lived or session-scoped authority in a way that fits the existing NixOS and age/agenix model? - What audit signal would prove that a given service credential did not enter the agent environment, logs, shell history, or persistent workspace? - How should failures behave when a brokered service refuses a request: clear denial, human approval path, capability escalation request, or something else? ## Non-goals for now - Choosing a concrete proxy, token exchange, socket, network, or control-plane implementation. - Replacing age/agenix or the existing private `secrets` authority. - Broadening what agents can do before the authority model is understood. - Treating Netclode's exact design as the target architecture.

No labels

No milestone

No project

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#13

No description provided.

Rows
Columns