Bob has capabilities for coding and system interaction. To use safely, follow these guidelines.

Security checklist

Configure .bobignore to restrict file access
Review and limit auto-approve settings
Handle secrets securely
Use MCP with proper authentication and encryption
Review Bob's output before implementing

You can control Bob's file access by configuring which directories and file types it can interact with. The .bobignore file uses the same syntax as .gitignore and should be one of the first security measures you implement when setting up Bob.

Setting up `.bobignore`

Create a .bobignore file in your workspace

Add patterns for sensitive files and directories. Include patterns for any non-approved data types.

.bobignore

# Example .bobignore patterns
.env
secrets/
*.key
config/credentials.json

Bob actively monitors the .bobignore file, and any changes are automatically applied. For detailed information, see Using .bobignore to Control File Access.

Understanding limitations

While .bobignore effectively controls Bob's access through its tools, it has some important limitations:

It only applies to files within your current workspace
Some write operations might bypass restrictions
It does not create a system-level sandbox

Review the complete key limitations and scope to understand how .bobignore protects your files.

Auto-approve settings

With Bob, you can automatically approve various actions without confirmation prompts. While this speeds up your workflow, it significantly increases security risks.

Warning:

Auto-approve settings bypass confirmation prompts, giving Bob direct access to your system. This can result in data loss, file corruption, or worse. Command line access is particularly dangerous, as it can potentially run harmful operations.

High-risk auto-approve settings

Setting	Risk	Recommendation
Edit files	High	Enable only in controlled environments
Execute commands	High	Use whitelist and avoid wildcards
Use MCP servers	Medium-High	Only with trusted servers
Read files	Medium	Consider sensitive data exposure

Always review Bob's output to ensure it is accurate and that any generated code will act as intended. Never inherently trust output from any AI system.

For detailed information on each setting and its security implications, see Auto-Approving Actions.

Handling secrets securely

Never provide secrets directly to any AI system, including Bob. Even temporary inclusion of secrets in code can lead to unintended exposure.

Best practices for secrets management

Store secrets in environment variable files
Ensure both .gitignore and .bobignore restrict access to files that store secrets
Use secret management tools when possible
Follow the principle of least privilege when assigning credentials - only grant the minimum permissions necessary for each task.

Delegation of permissions

AI systems should not leverage credentials that allow them to act on your behalf without your intervention and review. When AI systems need to act on your behalf:

Use delegation mechanisms like OAuth
Implement time-limited tokens
Monitor and audit all actions

Using MCP securely

Model Context Protocol (MCP) extends Bob's functionality by connecting to external tools and services. While powerful, MCP connections require careful security consideration.

MCP architecture overview

MCP uses a client-server architecture:

Bob acts as the host containing the MCP client
The client connects to MCP servers (local or remote)
Servers provide additional tools and capabilities

Security requirements for MCP servers

When using MCP servers, practice the following guidelines:

Authentication: Verify the identity of users accessing the server
Encryption: Secure data in transit between Bob and the server
Access controls: Limit what actions the server can perform
Auditing: Track all actions for accountability

Remote MCP servers must adhere to the same security requirements as any traditional server infrastructure, including endpoint protection, network restrictions, and proper access controls.

For shared MCP servers, ensure proper auditability and accountability so actions can be traced.

Additional security considerations

Review generated content: Always verify Bob's output before implementing it
Regular updates: Keep Bob and its dependencies updated
Security training: Ensure team members understand AI security risks
Incident response: Have a plan for addressing potential security incidents
Workspace isolation: Consider using dedicated workspaces for sensitive projects
Permission scoping: Limit Bob's access to only what is needed for specific tasks

By following these security best practices, you can leverage Bob's powerful capabilities while maintaining a secure development environment.

Security guidelines