|
IBM BOB V2.0 — FORTNIGHT 7 OF 7
Secure & Govern
File Access · Auto-Approve · Secrets · MCP Security · Governance
Put the guardrails in place: control what Bob can touch, approve deliberately, keep secrets out, and govern agentic development at team scale on IBM Bob V2.0.
Weeks 13–14 • Labs 15–16 • Security Checklist • Resources
|
|
Fortnight 7 Overview
Lock down Bob for real work: restrict file access with .bobignore, tune auto-approve to your risk, keep secrets safe, secure MCP, and govern agentic work at team scale. Built on the official Security guidelines.
• Week 13: File access & approvals — .bobignore, auto-approve risk tiers, reviewing output
• Week 14: Secrets, MCP security & team governance — credentials, custom-mode tool limits, shared standards
Requires: IBM Bob V2.0 (v2.0.2+). Most teams run on the SaaS service; enterprise and on-prem options exist if governance requires them.
The 5-point security checklist: (1) .bobignore for file access (2) limit auto-approve (3) handle secrets safely (4) MCP with auth + encryption (5) review output before implementing.
|
|
FN 1 ✓
Start
|
FN 2 ✓
Build
|
FN 3 ✓
Modernize
|
FN 4 ✓
Ship
|
FN 5 ✓
Automate
|
FN 6 ✓
V2 Power
|
FN 7 ←
Secure
|
Fortnight 7 — Learning Plan
|
WEEK 13 | Control File Access & Approvals
|
|
Objective: Restrict what Bob can read and change with .bobignore, and set auto-approve to match your project's risk.
Read: Security guidelines · Ignoring files · Auto-approve · Best practices
Lab: Lab 15 — Lock down a repo with .bobignore and risk-tiered auto-approve
Checklist: □ .bobignore created □ secrets/keys excluded □ auto-approve reviewed □ command auto-approve left off for untrusted work □ understood .bobignore limitations
|
|
WEEK 14 | Secrets, MCP Security & Team Governance
|
|
Objective: Keep secrets out of Bob's reach, secure MCP connections, and govern agentic work across a team with tool-limited custom modes and shared standards.
Read: Custom modes · Understanding MCP · API keys · Enterprise plan overview
Lab: Lab 16 — Build a read-only, tool-limited review mode and secure an MCP server
Checklist: □ secrets handled outside the repo □ MCP uses auth + encryption □ read-only custom mode created □ mode shared via version control □ Bob output reviewed before merge
|
Fortnight 7 — Labs
Use github.com/IBM/bob-demo or your own repo, on IBM Bob V2.0.
Lab 15 — Lock Down a Repo (.bobignore + Auto-Approve)
|
Time: ~40 min | Difficulty: Beginner–Intermediate | Mode: Agent, Ask
Goal: Restrict Bob's file access and set deliberate approvals before doing real work.
|
1. Create .bobignore. In your project root, add patterns for anything sensitive (same syntax as .gitignore):
|
# .bobignore
.env
secrets/
*.key
config/credentials.json
*.pem
.aws/
|
2. Confirm it applies live. Bob monitors .bobignore and applies changes automatically. In Ask mode, try: @config/credentials.json summarise this — Bob should refuse/skip the ignored file.
3. Review auto-approve. Open Settings → Auto-Approve. For untrusted or production code, keep Edit files and Run commands OFF — command auto-approve is the highest-risk setting. Use task-level approvals for one-off trusted batches.
4. Know the limits. .bobignore only covers files in the current workspace, some write ops can bypass it, and it is not a system sandbox — so still review output.
|
✅ Done when
• .bobignore blocks an ignored file from being read
• Auto-approve reviewed; command auto-approve off for untrusted work
• You can state two .bobignore limitations
|
Lab 16 — Governed Review Mode + Secure MCP
|
Time: ~45 min | Difficulty: Intermediate | Mode: Custom mode, Agent
Goal: Create a read-only reviewer mode the whole team can share, and connect an MCP server securely.
|
1. Create a tool-limited mode. Settings → Modes → Edit Project Modes, add a read-only reviewer (no edit, no command):
|
customModes:
- slug: reviewer
name: 🔍 Reviewer
roleDefinition: Read-only security & quality reviewer.
whenToUse: Reviewing code without changing it.
groups:
- read
|
2. Secure your MCP servers. In Settings → MCP Servers, use authenticated, encrypted endpoints only. Never hardcode tokens — keep them out of the repo and out of .bob/mcp.json (add it to .bobignore/.gitignore).
3. Share governance with the team. Commit the .bob/ directory (modes, rules) to version control so every teammate inherits the same guardrails. Project-level modes take precedence over global ones.
4. Keep humans in the loop. Governance rule of thumb: read operations can be auto-approved; state-changing actions (edits, commands, MCP calls) should be reviewed. Always review Bob's output before merge.
|
✅ Done when
• Read-only reviewer mode appears in the mode picker
• MCP server uses auth + encryption, no secrets in the repo
• .bob/ committed so the team shares the same controls
|
Resource Library
|
Topic
|
URL
|
|
Security guidelines
|
bob.ibm.com/docs/ide/security/bob-security-guidance
|
|
Ignoring files (.bobignore)
|
bob.ibm.com/docs/ide/configuration/bobignore
|
|
Auto-approve
|
bob.ibm.com/docs/ide/features/auto-approving-actions
|
|
Custom modes (tool groups)
|
bob.ibm.com/docs/ide/configuration/custom-modes
|
|
Understanding MCP
|
bob.ibm.com/docs/ide/configuration/mcp/understanding-mcp
|
|
API keys
|
bob.ibm.com/docs/ide/account/api-keys
|
|
Best practices
|
bob.ibm.com/docs/ide/getting-started/best-practices
|
|
Enterprise plan overview
|
bob.ibm.com/docs/ide/enterprise/enterprise-index
|
|
Changelog (V2 updates)
|
bob.ibm.com/docs/ide/changelog
|