Create

Sign in to ReadmeX

or

How we handle your data: Privacy Policy

ReadmeX

Your AI reading companion

What would you like to catch up on?

Pick a briefing, or ask your own question.

Your community and people briefings stay personal to you.

substrate

substrate: A security-hardened, zero-trust runtime for sandboxed agents and tools on Kubernetes.

What problem it solves

Running untrusted agents and tools requires isolation, identity, network controls, and careful management of workloads that spend much of their time idle. Agent Substrate addresses these needs by providing a Kubernetes-based runtime that sandboxes each workload, withholds sensitive credentials, mediates outbound traffic, and suspends idle actors until they are needed.

Key features

  • Sandboxed workload isolation — Every actor receives a dedicated gVisor or Cloud Hypervisor microVM sandbox with segregated compute, network, and storage. Plain Linux containers are not supported.

    Source: README

  • Snapshot and resume scheduling — Idle actors can be suspended and restored on available workers. Their working memory and filesystem state are captured in snapshots so in-flight sessions and tool state survive hibernation cycles.

    Source: README

  • Per-actor identity and credential isolation — Active actors receive short-lived SPIFFE X.509 certificates, while approved outbound credentials are injected outside the sandbox by the egress gateway.

    Source: README

  • Default-deny networking — Actors begin with private network stacks and no inbound path except through the ingress router. Outbound traffic is restricted by the egress gateway, and the gateway can be replaced with other policy enforcement systems.

    Source: README

  • Framework-agnostic Kubernetes runtime — The runtime accepts standard OCI container images without requiring agent SDK changes. It supports agent, inference, training, reinforcement learning, and stateful tool workloads on standard Kubernetes infrastructure.

    Source: README

Quick start

Copied verbatim from the project's README.

# create cluster and local registry
hack/create-kind-cluster.sh

# make ate-setup target the kind cluster; set this in every shell that runs
# ate-setup, including for the demo walkthroughs
export ATE_INSTALL_KIND=true

# install Substrate
go run ./cmd/ate-setup deploy ate-system --credential-provider='{"name":"k8s.io"}' \
  --ingress-allowed-spiffe-ids=spiffe://cluster.local/ns/ate-system/sa/atenet-client

# install counter demo
go run ./cmd/ate-setup deploy demo counter

# install kubectl-ate
go install ./cmd/kubectl-ate

# create a counter actor in the demo's atespace (--template names the
# actor template, resolved in the actor's atespace)
kubectl ate create actor my-counter-1 -a ate-demo-counter --template counter

# serve a local proxy on port 8000 that sends requests to the actor through the
# network router
kubectl ate proxy actor my-counter-1 -a ate-demo-counter
curl -X POST -i http://localhost:8000/

Who it may suit

This project may suit Kubernetes operators and platform teams building isolated execution infrastructure for untrusted agents or other mostly-idle stateful workloads. It may also suit developers who want framework-independent sandboxing without introducing an agent SDK.

Topics to discuss

  • Which threat models and workload types should guide the next set of security controls?

  • How should actors, workers, atespaces, and templates be composed in practical deployments?

  • Which integrations and policy enforcement points would be most useful to build next?


Written by ReadmeX AI from the project's README, source and public GitHub data; it may contain mistakes.

Read the original README https://github.com/agent-substrate/substrate#readme

ReadmeX opened this community for a trending project; it is not run by the project. Maintainers can claim it from the community page.

github.comhttps://github.com/agent-substrate/substrate

Comments

…