diff --git a/docs/12-contribute-to-zarf/3-nerd-notes.md b/docs/12-contribute-to-zarf/3-nerd-notes.md
index 21a7c58ad9..5ae96dc540 100644
--- a/docs/12-contribute-to-zarf/3-nerd-notes.md
+++ b/docs/12-contribute-to-zarf/3-nerd-notes.md
@@ -12,7 +12,7 @@ Zarf is written entirely in [go](https://go.dev/), except for a single 868Kb bin
 - The OCI Registries used are both from [Docker](https://github.com/distribution/distribution)
 - Currently, the Registry and Git servers _are not HA_, see [#375](https://github.com/defenseunicorns/zarf/issues/376) and [#376](https://github.com/defenseunicorns/zarf/issues/376) for discussion on this
 - To avoid TLS issues, Zarf binds to `127.0.0.1:31999` on each node as a [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) to allow all nodes to access the pod(s) in the cluster
-- Until [#306](https://github.com/defenseunicorns/zarf/pull/306) is merged, during helm install/upgrade a [Helm PostRender](https://helm.sh/docs/topics/advanced/#post-rendering) function is called to mutate images and [ImagePullSecrets](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) so the deployed resources use the NodePort binding
+- Zarf utilizes a [mutating admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) called the [`zarf-agent`](https://github.com/defenseunicorns/zarf/tree/main/src/internal/agent) to modify the image property within the `PodSpec`. The purpose is to redirect it to Zarf's configured registry instead of the the original registry (such as DockerHub, GCR, or Quay). Additionally, the webhook attaches the appropriate [ImagePullSecret](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) for the seed registry to the pod. This configuration allows the pod to successfully retrieve the image from the seed registry, even when operating in an air-gapped environment.
 - Zarf uses a custom injector system to bootstrap a new cluster. See the PR [#329](https://github.com/defenseunicorns/zarf/pull/329) and [ADR](https://github.com/defenseunicorns/zarf/blob/main/adr/0003-image-injection-into-remote-clusters-without-native-support.md) for more details on how we came to this solution.  The general steps are listed below:
   - Get a list of images in the cluster
   - Attempt to create an ephemeral pod using an image from the list