adding remote secret proxy pattern

src/main/resources/explanations/challenge69_reason.adoc

@@ -16,6 +16,7 @@ What to do instead:
 - Give every consumer their own short-lived, least-privilege credential instead of one shared team token.
 - Scan skill files with a secret scanner in pre-commit and CI, just like you scan source code.
 - Treat a secret that ever appeared in a skill as compromised and rotate it.
+- In case of (autonomous and/or remote) agents: always use something like a secrets proxy pattern.
 ----
 
 [NOTE]

src/main/resources/explanations/challenge72_reason.adoc

@@ -24,6 +24,7 @@ What to do instead:
 - Review agent transcripts before saving or sharing them, just as you would review a pull request.
 - Treat any transcript that read from a secrets source as potentially compromised, and rotate the exposed credentials.
 - Use short-lived, scoped tokens for staging deployments so that exposure has limited blast radius.
+- In case of (autonomous and/or remote) agents: always use something like a secrets proxy pattern.
 ----
 
 [NOTE]

src/main/resources/explanations/challenge73_reason.adoc

@@ -21,6 +21,7 @@ What to do instead:
 
 - Keep credentials out of the instruction files and let the agent read them
   from the environment, for example `$STAGING_DEPLOY_TOKEN`.
+- In case of (autonomous and/or remote) agents: always use something like a secrets proxy pattern.
 - Document *which* variable is required and *where* to obtain it, never the
   value itself.
 - Give every consumer a short-lived, least-privilege credential instead of one