docs(integrations): add Guarding the model endpoint (offline I/O guard for Lemonade)

[eeee2345]

Closes #1689

Adds a docs page for a vendor-neutral pattern that guards the model I/O boundary — prompt injection in content, tool poisoning on the MCP path — in front of the Lemonade endpoint, fully offline. It complements gaia.governance (which guards tool calls) for defense in depth.

What's here (docs-only):

• docs/integrations/guard-proxy.mdx — the pattern, how it complements gaia.governance, an offline quick-start, vendor-neutrality, and honest limitations.
• docs/docs.json — adds the page to the Integrations nav.
• docs/security/connections.mdx — one cross-link under "See also".

Links the open MIT ruleset (Agent Threat Rules) and a MIT reference implementation (runs the demo fully offline). GAIA core takes no new dependency; nothing is vendored.

Notes for review:

• Badge is community (vs the siblings' development) to signal this is a third-party pattern, not a GAIA-developed feature — happy to switch to development if you'd prefer consistency.
• Kept this strictly docs-only. I'd mentioned a pointer in the gaia.governance README — happy to add that as a small follow-up if useful, but left src/ untouched so this stays a fast docs review.
• amd-gaia.ai links carry the /docs/ prefix per your note.

Thanks @kovtcharov for the placement guidance.

[github-actions]

Review: docs(integrations): Guarding the model endpoint

Summary

Clean, accurate, docs-only PR — safe to merge. It adds one Integrations page describing a vendor-neutral offline guard proxy at the model I/O boundary, wires it into docs/docs.json nav, and adds one cross-link. I verified the technical claims against the codebase and they hold: the gaia.governance API (PolicyEngine.evaluate_action(ActionRequest) → GovernanceDecision with .decision ∈ ALLOW/BLOCK/REVIEW), the README.md it links, and the 13305/api/v1 Lemonade endpoint are all correct. Scope is tight and src/ is untouched, exactly as the description claims. No prompt-injection content in the diff.

Issues Found

🟢 Minor — H1/Badge ordering differs from sibling pages (docs/integrations/guard-proxy.mdx:27-33)
The three sibling pages (n8n.mdx, mcp.mdx, vscode.mdx) all order it # H1 then <Badge> immediately after. This page leads with an <Info> block, then the H1, then the badge. Renders fine in Mintlify either way — purely a consistency nit. Optional:

# Guarding the model endpoint

<Badge text="community" color="orange" />

<Info>
  **Open ruleset (MIT):** [Agent Threat Rules](https://github.com/Agent-Threat-Rule/agent-threat-rules) · **Reference implementation (MIT):** [atr-lemonade-guard](https://github.com/Agent-Threat-Rule/atr-lemonade-guard). This page documents an integration pattern — GAIA core takes no dependency on either.
</Info>

🟢 Minor — external repos are unverifiable third-party links (guard-proxy.mdx:28,60,71)
The Agent-Threat-Rule/* GitHub repos are external and can't be validated from this repo. Not a blocker — the page is explicit that this is a community pattern and GAIA vendors nothing — just flagging that these links live outside maintainer control and may rot.

On the open question in your description: the community badge is a sensible signal that this is a third-party pattern rather than a GAIA-built feature. I'd keep it as-is unless a maintainer prefers strict visual consistency with the development siblings — your call to defer to @kovtcharov-amd.

Strengths

• Claims verified against real code, not asserted. The governance API surface, README path, and Lemonade endpoint all match the codebase — rare precision for a docs PR.
• Honest "Honest limitations" section. Framing I/O-layer detection as best-effort heuristic (not a guarantee) and pointing to defense-in-depth is exactly the right tone for a security-adjacent page.
• Disciplined scope. Docs-only, no src/ changes, no new dependency, nav + cross-link correctly updated. Internal links use bare /path form consistent with the rest of docs/.

Verdict

Approve. No blocking issues; the two minor nits are optional polish.