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.
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:
untrustedcoding-agent workshop that edits Terraform code and holdszero infrastructure credentials, and
trusted plan-runnerworkshop that holds Vault/state/cloud credentialsand runs
terraform planon 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
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.
or for the ACLs
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.