docs(llms): setup agents documentation

docs/agent-guides/security.md

@@ -0,0 +1,42 @@
+# Security boundaries
+
+Use for auth, external input, files, integrations, assets, URLs, or secrets.
+
+## Untrusted inputs
+
+Validate/parse before trust:
+
+- HTTP bodies, params, headers, cookies, websocket messages;
+- project files, migrations, spreadsheets, imports;
+- custom HTML/CSS/views, translations, served assets;
+- automation payloads, third-party responses;
+- externally supplied paths/filenames.
+
+Validate shape and domain constraints at the owning boundary. Keep existing parser/validation layers; avoid downstream defensive casts.
+
+## Authentication and authorisation
+
+- Keep protected routers behind auth middleware in `apps/server/src/app.ts`.
+- Preserve auth across prefixed routes, redirects, websockets, generated links.
+- Scope session cookies to runtime prefix; isolate hosted clients.
+- Authentication never grants arbitrary file, path, project, or rundown access.
+
+## Files, URLs, integrations
+
+- Use established path/file helpers. Reject traversal and unexpected types.
+- Build URLs with `URL` or existing helpers. Check open redirects, SSRF, protocol changes, token leaks.
+- Encode/constrain untrusted HTML, CSS, filenames, headers, log values.
+- Preserve cloud limits on local-network capabilities.
+
+## Secrets and diagnostics
+
+- Never commit/log passwords, hashes, tokens, credentials, cookies, private project content.
+- Errors: useful, but no internal paths, stacks, credentials, sensitive payloads.
+- Keep tokens in existing session/authenticated-share flows. Avoid new URL-token patterns.
+
+## Review prompts
+
+- Where does input become trusted?
+- Validation once at owner, then useful type?
+- Can one prefixed client cross another client's session/assets?
+- Can logs, responses, redirects, URLs leak secrets?