Skip to content

Feature request: declarative per-workshop network policy / egress control #927

Description

@nsakkos

Hi team,

I'm building a trust-boundary pattern for running AI coding agents against
Infrastructure-as-Code (is-tf-plan-broker).
It uses two sibling Workshop projects separated by a trust boundary:

  • an untrusted coding-agent workshop that edits Terraform code and holds
    zero infrastructure credentials, and
  • a trusted plan-runner workshop that holds Vault/state/cloud credentials
    and runs terraform plan on the agent's behalf.

They communicate only through a shared host file spool.

A core part of the design's is defense-in-depth, which involves restricting the agent workshop's network egress. For example, I want the untrusted workshop to be able to reach the public internet, but I don't want it to be able to reach any sensitive infrastructure (Vault, Cloud APIs, JAAS etc).

To work around this, I currently

  • create an LXD network ACL with the deny/allow egress rules
  • create a dedicated bridge and bind the ACL to it at the network level
  • repoint the workshop's instance's NIC onto that bridge and restart it.

To make this solution reproducible and not dependent on LXD, I would prefer a way to declare network attachment and/or egress policy in the workshop definition.

E.g.

network:
  name: my-isolated-bridge 

or for the ACLs

   network:
     egress:
       default: allow
       deny:
         - 10.0.0.0/8      # Internal infrastructure
         - X.X.X.X/32      # a specific IP I don't want the workshop to have access to

I think that first-class support for network policies aligns with Workshop's goals of enabling safe, sandboxed experimentation and would help accelerate agentic engineering by making trust boundaries declarative. It's far easier to let an agent run in full auto-pilot when you can prove (from committed configuration) that it can't reach sensitive resources.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions