grok-bot

Safety: never put secrets in chat (ops pattern)

Secrets live in an env / secret store — never in Bot description, skills, routines, AGENTS.md, or a chat paste. On an agent-ops desk that means API keys, tokens, cookies, webhook secrets, and payment credentials stay off every chat surface; the Bot injects them at runtime (or the human does) and redacts them from logs. Pair this with approval gates (stop before send / publish / pay) so a leaked chat doesn’t also leave the box. Env var names are fine in docs; values are not. If a specialist needs access to finish a job, the job text names the env var, not the value.

Who this is for

Solo founders and small ops desks already in Cursor + Grok Bot who keep pasting tokens into Bot text “just for this run.” If your pain is “the key showed up in a skill / mcp.json / chat thread,” this is the desk runbook habit — not a scare piece. Seat templates and stop language: Grok Bot role templates that stop before send/publish/pay. Lead coordination: What is a Lead Bot in a Grok Bot group?.

What counts as a secret on an agent-ops desk

Treat anything that grants access or spends money as a secret:

KindExamples (names only — never paste values)
API keys / tokensProvider API keys, personal access tokens, bot tokens
OAuth client material`CLIENT_SECRET`, refresh tokens; treat static `CLIENT_ID` carefully when the file is published
Session / cookie materialBrowser session cookies, signed-in app cookies
Webhook / signing secretsStripe webhook secrets, HMAC keys
Payment credentialsCard numbers, Stripe secret keys, payout credentials

Env var names are fine in docs (`STRIPE_SECRET_KEY`, `GITHUB_TOKEN`). Values are not. Prefer “set `TOKEN_ENV` in your secret store” over inventing placeholder blobs in public posts.

Allowed surfaces vs forbidden surfaces

SurfaceSecrets?Why
Env / secret store / OS keychainYes — only hereRuntime inject; not copied into prompts
Local private config (gitignored, not published)Yes, with careStill prefer env refs over inline values
Bot descriptionNeverShared, logged, often re-pasted into other seats
Skill / role templateNeverReused across jobs; easy to commit or share
Routine configNeverSchedules work; must not carry credentials
`AGENTS.md` / repo agent filesNeverShared with every agent that reads the tree
Chat paste / screenshots / failure cards with live valuesNeverThreads get forwarded; screenshots get screenshotted
Published `mcp.json` / docs / blogNeverPublic forever; use env refs or omit

If a specialist needs a credential to finish a job, the human (or a sanctioned secret tool) supplies it at runtime — the job text names the env var, not the value.

Ops pattern: inject · redact · scrub

Three habits, boring on purpose:

  1. Inject at runtime — Bot / MCP / shell reads from env or a secret store. Descriptions and skills say *which* var to use, never the value.
  2. Redact in logs — Treat tool output and failure cards as public. Replace values with `[REDACTED]` or the var name before a specialist files a review pack.
  3. Scrub templates before share — Before you export a skill, role pack, or `mcp.json` example, search for key-shaped strings and strip them. Publish shapes, not credentials.

For remote MCP Connect, static `CLIENT_ID` paths are a real pattern — but a published `mcp.json` must not carry secrets. Keep client secret material in env; document the field names only. Companion pillar: Build a remote MCP server with OAuth that Cursor and Claude can both Connect to.

Pair with approval gates

Secret-free chat and stop-before-send are the same desk hygiene:

  • A leaked Bot description without secrets is embarrassing; a leaked description with a Stripe key is an incident.
  • Approval gates (never auto-send / publish / pay) mean even if chat history escapes, the Bot still couldn’t leave the box alone.
  • Lead + specialist desks keep credentials out of handoff text the same way they keep outbound sends behind a human gate — see Lead Bot in a Grok Bot group and the stop list in role templates….

Put both rules in the Bot description in plain language: no secrets in this text, and stop before send / publish / pay.

Failure card (pin this)

SymptomLikely causeFix
Key / token appears in chatPasted “just for this run” into prompt or Bot textRotate the credential; move to env; scrub the thread/description
Secret committed in `mcp.json` or skillExample copied with a live valueRotate; gitignore / purge history if needed; republish placeholder-only shape
Specialist “helps” by pasting a token into a skillJob asked for access instead of an artifactJob = reviewable file; human injects secret at runtime
Webhook secret in a failure card screenshotLog dump included raw headers/bodyRedact before filing; teach specialists env-name-only cards
`AGENTS.md` contains API keysRepo agents treated as a secret storeStrip; document var names only; store values in env / CI secrets
Payment creds in a routineRoutine treated as permission + vaultRoutines schedule drafts; secrets stay in env; pay stays human-gated

Debug order: find where the value was pasted → rotate → move to env / secret store → scrub every chat surface (description, skill, routine, `AGENTS.md`, committed configs) → confirm approval stops still hold.

What Cheat Sheet + Agent Starter are for

The Cheat Sheet is the skimmable gate / safety checklist mindset for this desk — roster, approval card, and “secrets stay in env” hygiene in one pocket reference. Soft path today: start on /free (Harness Desk Starter — seat, done-artifact skill, gate card). When you want harness depth (role pack + agent-ops files with the same contract), use the Agent Starter Kit ($47).

Stay in agent-ops — never Domo-as-kit-ROI, never scare metrics, never example posts that include real-looking secrets.

Soft next step

Move one live credential out of chat surfaces today — Bot description, skill, or `AGENTS.md` — into env / secret store, then rotate it. Soft ladder: /free for the starter desk, Cheat Sheet for the gate/safety checklist mindset, then the Agent Starter Kit ($47) when you want the harness pack. No rush — ship the “secrets stay in env” line into your own runbook either way.

FAQ

Can I put a CLIENT_ID in an mcp.json that I publish?+

Prefer documenting the field and letting operators supply their own client material. Never publish a CLIENT_SECRET or other secret values. If a static CLIENT_ID is required for a non-DCR path, treat anything secret-adjacent as env-only and keep published examples credential-free. See the MCP OAuth pillar.

Do Bot descriptions ever need API keys?+

No. Descriptions hold the job and the stop rules. Skills hold how-to. Credentials inject at runtime from env / secret store.

Where do secrets live for repo agents (AGENTS.md)?+

Not in AGENTS.md. Document env var names and approval stops there; store values in env, CI secrets, or a secret manager. Mirror the same “no secrets in chat surfaces” rule Cursor / Claude Code agents inherit.

What if a specialist already pasted a token?+

Rotate the credential first. Then scrub the skill, Bot description, chat thread, and any committed file. Redefine the job as an in-box artifact; the human (or sanctioned store) supplies access next time.

How does this relate to approval boundaries?+

Same desk. Secret-free surfaces limit blast radius if chat leaks; stop-before-send / publish / pay limits blast radius if the Bot runs hot. Put both in the Bot description. Detail lives in the Grok Bot role templates post.

Is a screenshot of a “working” Connect UI safe to share?+

Only after you redact tokens, cookies, and query strings. Prefer a failure card with symptom / cause / fix and env names — no live values.

What’s the soft next step?+

Pick one Bot description and one skill; scrub any credential-shaped strings; rewrite them to name env vars only; confirm stop-before-send still holds.

Get the free starter

Value first, then a kit when you are ready. No fake urgency. Start with Harness Desk Starter at /free.