Googles Agent Identity is already built around SPIFFE but others are not.
I believe the substrate egress-gateway needs to handover the internal SPIFFE one to an external system (e.g. Entra Agent ID). Not sure if that should be part of substrate or kagent/ax/..
IIUC agent-sandbox and agent-substrate (the one ax builds upon) are similar. Agent-sandbox is more k8s-native, while agent-substrate is less so.
Personally I think that this kind of workload is better off not being tied too much into kubernetes. I've worked with crossplane and other controller who put a lot of load on the k8s-apiserver and etcd and can easily slow the whole machinery down / grind them to a halt.
Agent Substrate was built to provide a few (important) things over Agent Sandbox:
* More efficient usage of compute by timeslicing agents (Substrate Actors), which requires fast suspend and resume (using gVisor or cloud-hypervisor snapshots), as well as keeping the K8s control plane out of the critical path (so agents can't be stored as resources in the K8s database).
* Deep inspection of outgoing requests using an egress gateway
* Minimizing the exposure of credentials to unpredictable agent control (so they can't upload access tokens to pastebin).
Achieving those goals ultimately required a significantly different design from Agent Sandbox.
I believe the substrate egress-gateway needs to handover the internal SPIFFE one to an external system (e.g. Entra Agent ID). Not sure if that should be part of substrate or kagent/ax/..