Problem
A SWML document with SWAIG functions typically embeds webhook credentials, which makes the document itself a secret — yet every SWML example in the docs shows a plain public URL, and no page in the SWML section says the endpoint serving the document needs protecting.
The asymmetry: the Agents SDK path is safe by construction (basic auth on the SWML endpoint by default, SWML_BASIC_AUTH_PASSWORD on the production checklist at /docs/server-sdks/guides/production), and the Compatibility API documents webhook signing at /docs/compatibility-api/guides/webhook-security. The hand-written-SWML path — which is what the SWML reference documentation teaches — has no equivalent guidance anywhere.
Fix
- A security note on the SWML/SWAIG reference pages: the document contains credentials; serve it only from an authenticated endpoint (basic auth at minimum) over HTTPS.
- Surface the endpoint-authentication guidance (the reasoning behind
SWML_BASIC_AUTH_PASSWORD) outside the SDK docs, where hand-written-SWML developers will find it.
- Cross-link from the SWAIG auth examples issue (standardize on
user:pass@ URL form).
Problem
A SWML document with SWAIG functions typically embeds webhook credentials, which makes the document itself a secret — yet every SWML example in the docs shows a plain public URL, and no page in the SWML section says the endpoint serving the document needs protecting.
The asymmetry: the Agents SDK path is safe by construction (basic auth on the SWML endpoint by default,
SWML_BASIC_AUTH_PASSWORDon the production checklist at/docs/server-sdks/guides/production), and the Compatibility API documents webhook signing at/docs/compatibility-api/guides/webhook-security. The hand-written-SWML path — which is what the SWML reference documentation teaches — has no equivalent guidance anywhere.Fix
SWML_BASIC_AUTH_PASSWORD) outside the SDK docs, where hand-written-SWML developers will find it.user:pass@URL form).