Bot Security Checklist
A practical pre-launch review for a secure bot. What each risk is, how Octocom contains it, and the specific configuration decisions that are yours to make.
The other security pages explain why an Octocom bot is safe to trust. This one is the practical companion: a short, concrete review to run before you put a bot live, so the architecture's guarantees actually hold for your configuration.
The key idea to carry in: Octocom provides the guarantees, but you draw the boundaries. Almost every security outcome comes down to configuration decisions — which tools exist in which situation, what gets verified, and what stays out of the model's reach. This page makes those decisions explicit.
Read the three principle pages first if you haven't — AI Security, AI Reliability, and Authentication & Access Control. This checklist assumes them.
Risks, and who handles what
For each risk, Octocom's architecture does the heavy lifting — but there's a configuration decision that's yours. This table is the whole model on one screen.
| Risk | How Octocom contains it | What you configure |
|---|---|---|
| System-prompt / instruction leak | The prompt holds no standing secrets; sensitive instructions are delivered conditionally via workflow variants | Keep secrets out of the prompt; deliver sensitive rules through variants, never a global bot rule that states them to everyone |
| Prompt injection (direct and indirect) | The model has no privileged capability to hijack — it can't call an ungranted tool or exceed a coded limit no matter what it's told or reads | Gate every sensitive action behind a condition provider and a bounded tool |
| Unauthorized data access (someone else's order, PII) | Tools verify identity before returning anything; data is never sitting in the prompt to leak | Set the verification strength per flow to match how sensitive the data is |
| Unauthorized actions (refund/cancel abuse) | Privilege is derived from verified data; actions re-check state server-side; tool effects are bounded in code | Compute privilege in a condition provider; never trust a model-supplied flag; cap what each action can do |
| Bulk data harvesting (catalog, pricing) | Search-shaped tools (not export), an index scoped to public fields, and rate limits | Use search tools; keep internal fields (cost, stock, unreleased) out of the index |
| Costly, nuanced misjudgment | Human-in-the-loop approval on the decision that warrants it | Route the rare high-stakes case to a human for final sign-off |
| Bot mistakes (omission, hallucination) | Answers are grounded in your material; validation checks run around the loop | Fill knowledge gaps; add workflows for uncovered situations |
Pre-launch checklist
Walk these before going live. Each item is something you can actually verify in your configuration.
Information exposure
- No credentials, internal data, or secrets live in the system prompt or in bot rules.
- Sensitive or conditional instructions are delivered through workflow variants — not a global rule that states the policy to every customer.
- Everything the bot can reach is either public, gated behind identity verification, or (for large public data) scoped to the same fields your website already shows.
Identity and authentication
- For each flow that exposes private data, the verification strength matches the sensitivity of what's behind it.
- Identity checks rely on something hard to forge (a one-time code, a website token, a verified email sender) rather than a guessable identifier alone — or you've made a deliberate, documented trade-off to accept lighter checks because nothing sensitive is exposed.
- Privilege (VIP, B2B, "verified") is computed in a condition provider from your systems, never taken from a value the model supplies.
Actions
- Each sensitive action is granted only inside the workflow variant whose conditions are met — never globally available.
- Every action re-validates state server-side before it commits (e.g. not already refunded, within policy).
- Action effects are bounded in code (refund caps, allowed operations), not left to the model's discretion.
Human oversight
- Rare, high-stakes, hard-to-verify decisions route to a human for final approval, with the bot preparing the context.
Reliability
- The knowledge base covers your common questions; gaps are filled rather than left to the model to guess.
- Common situations have workflows; anything uncovered transfers to a human by default.
- Multi-step flows with model discretion (like retention) have firm instructions for the edge cases you care about.
Review
- You've tested each action and condition provider in the dashboard with real inputs — including hostile ones.
- You've reviewed the configuration from an attacker's point of view.
How to actually run the review
You don't have to eyeball this from memory — the system is built to be inspected:
- Test before you trust. Every action and condition provider runs from the dashboard test panel with inputs you choose, so you can confirm a gate holds before it's ever live.
- Trace any real turn. The debug view (and Octocom MCP) show the exact instructions the bot received, every tool call with its inputs and results, and the full set of tools it had available — so you can verify that a sensitive tool truly wasn't present when it shouldn't be.
- Get a second pair of eyes. Because it's all transparent, a capable model like Claude Opus or Fable — connected through Octocom MCP — can review your configuration for security gaps with you. Your account manager and our engineers can too.
Run this once before launch and revisit it whenever you add a workflow that touches sensitive data or actions. It's a short list, and getting it right is the difference between "the architecture can keep this safe" and "this is safe."