AI Bot Security Boundary Assessment Template

When you deploy an AI bot into production, you're making an implicit promise about where the security boundary lies. Does each bot instance run with unique credentials? Does a compromise affect one user or everyone? Most vendors don't make this clear until you're reading the incident postmortem.

This template helps you document exactly where each AI bot product draws its security boundary before you deploy it. You'll use it during vendor evaluation, architecture review, and when you're writing the security section of your deployment runbook.

Purpose of the Template

You need a structured way to compare how different AI bot products isolate credentials, execution contexts, and data. Without this comparison, you'll discover boundary mismatches only after a credential leak or when audit asks why three different bots share the same service account.

The template captures four critical dimensions:

• Credential scope: Does each bot instance get unique credentials, or do multiple instances share?
• Execution isolation: What's the smallest unit of isolation (user account, profile, container)?
• Default vs. optional security: Is the strongest boundary enabled out of the box, or does it require Docker and three config flags?
• Documentation alignment: Does the vendor's security model match what the product actually implements?

Prerequisites

Before you fill out this template, ensure you have:

• Access to the vendor's architecture documentation and security whitepaper
• A test environment where you can deploy multiple bot instances
• Credentials to check: Can you assign unique API keys per bot? Do bots inherit user tokens?
• Permission to run docker inspect or equivalent if the product uses containerization

You should also know your threat model. If you're evaluating bots that will access customer PII, you care deeply about credential isolation. If you're running internal documentation assistants, you might accept shared credentials within a team boundary.

The Template

# AI Bot Security Boundary Assessment
**Product**: [Product name and version]
**Assessed by**: [Your name]
**Date**: [YYYY-MM-DD]
**Deployment context**: [Production/staging, what data the bot will access]

## 1. Credential Scope
**Question**: If I deploy five instances of this bot, how many sets of credentials exist?

- [ ] Unique credentials per bot instance
- [ ] Unique credentials per user account
- [ ] Shared credentials across all instances
- [ ] Other: _______________

**Evidence**: [How you verified this - config inspection, API token count, vendor confirmation]

**Risk**: If one bot is compromised, what else is exposed?
[Your answer]

## 2. Execution Isolation Boundary
**Question**: What is the smallest unit of isolation?

- [ ] Container (each bot runs in its own container)
- [ ] Process with sandbox (OS-level isolation, e.g., seccomp, AppArmor)
- [ ] Profile or workspace (logical separation within shared runtime)
- [ ] User account (all bots under one user share state)
- [ ] None (single shared runtime)

**Default state**: Is this isolation enabled by default? YES / NO

**Configuration required**: [List steps to enable strongest isolation]

**Evidence**: [Command output, config file excerpt, or vendor doc reference]

## 3. Persistent State and Secrets
**Question**: Where does the bot store credentials and session data?

**Location**: [Filesystem path, database, secrets manager, environment variables]

**Shared or isolated**: [Is this storage unique per bot instance?]

**Encryption**: At rest? YES / NO  |  In transit? YES / NO

**Access control**: [Who can read these secrets - the bot user, root, anyone in the container?]

## 4. Documentation vs. Implementation Gap
**Question**: Does the vendor's stated security model match observed behavior?

**Vendor claims**: [Quote from security docs about isolation model]

**Observed behavior**: [What you actually saw in testing]

**Gap identified**: YES / NO

**If yes, describe**: [Specific mismatch - e.g., docs say unique creds, but all bots use same API key]

## 5. Compliance Mapping
Which controls does this boundary satisfy?

- [ ] [PCI DSS](https://www.pcisecuritystandards.org/) v4.0.1 Requirement 7.2.2 (unique user IDs)
- [ ] [SOC 2](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) CC6.1 (logical access controls)
- [ ] [ISO/IEC 27001:2022](https://www.iso.org/standard/27001) A.9.2 (user access management)
- [ ] [NIST CSF](https://www.nist.gov/cyberframework) PR.AC-1 (identities and credentials managed)
- [ ] Other: _______________

**Notes**: [Any gaps or partial compliance]

## 6. Deployment Decision
Based on this assessment:

- [ ] Approved for production with current boundary
- [ ] Approved only if [specific hardening steps] implemented
- [ ] Requires architectural changes: _______________
- [ ] Rejected - boundary insufficient for our threat model

**Justification**: [Your reasoning]

**Mitigations if approved**: [Compensating controls, monitoring, access restrictions]

Customizing the Template

For lower-risk deployments: You can skip Section 5 (compliance mapping) if you're not under regulatory requirements. Focus on Sections 1-3 to understand the blast radius of a compromise.

For high-security environments: Add a Section 7 for network isolation. Document whether the bot can make arbitrary outbound connections, whether it respects egress filtering, and what happens if it's compromised and used as a pivot point.

For multi-tenant SaaS: Expand Section 2 to include tenant isolation. If you're a SaaS provider deploying bots on behalf of customers, you need to verify that Customer A's bot can't access Customer B's data even if they share the same underlying infrastructure.

For specific products: Based on the facts from source, here's what you'd document:

• Grok Bot: Under Section 1, you'd note "shared credentials across all instances" because SpaceXAI launched it with a single persistent cloud computer assigned to the user account. Under Section 2, the boundary is "user account."

• Hermes: On August 17, Nous Research announced that Bot Mode would ship bundled and enabled by default in Hermes Agent v0.20.3. Under Section 2, you'd mark "Profile or workspace" and note "Default state: YES" because the profile-based boundary is on by default.

• OpenClaw: Under Section 2, you'd document "Process with sandbox" but mark "Default state: NO" because the sandbox mode is off by default and enabling it requires Docker backend. Section 2's "Configuration required" would list the Docker dependency.

Validation Steps

After you fill out the template, validate your findings:

1. Deploy two bot instances with different user accounts. Give them different API keys if the product supports it. Have Instance A create a file or set a configuration value. Can Instance B read it? If yes, your boundary is weaker than "user account."

2. Check the process table. Run ps aux | grep [bot-name] on the host. How many processes? Do they run as different users? If you see one process serving multiple bot instances, you've found shared runtime.

3. Inspect credentials in memory. If you have access, attach a debugger or use gdb to dump environment variables and memory. Do you see multiple API keys, or just one? This confirms whether credential isolation is real or cosmetic.

4. Test a simulated compromise. Give one bot instance a malicious prompt that attempts to read files outside its workspace. Can it access another bot's data? This tests whether the documented boundary holds under adversarial conditions.

5. Compare with vendor documentation. Open the security whitepaper and the architecture diagram. Does your assessment match what they claim? If not, document the gap in Section 4 and ask the vendor to explain before you deploy.

When you're done, you'll have a decision artifact that shows auditors and your CISO exactly what security boundary you're accepting and why. If a bot gets compromised six months from now, you'll know immediately what else is at risk.