Use Cases

This document explains where SecureMCP-Lite is immediately useful and what “good” adoption looks like.

1. Read-only repository assistant

Who this is for

• OSS maintainers
• reviewers
• developers using Claude Code, Codex, Cursor, or Copilot to inspect a codebase

Problem

You want the model to understand the repo, but you do not want it to mutate files, delete content, or wander outside the project root.

Recommended policy

Use ../examples/ai-safe-filesystem.ymlFile.

What success looks like

• read_file works inside the project
• list_dir works inside the project
• search_files works inside the project
• ../ traversal is blocked
• non-allowlisted tools never reach the target server

2. Guarded shell assistant

Who this is for

• platform engineers
• DevOps teams
• developers using agentic terminal workflows

Problem

You want shell capability, but not unrestricted shell capability.

Recommended policy

Use ../examples/ai-safe-shell.ymlFile.

What success looks like

• safe diagnostic commands can run
• obvious high-risk commands are blocked
• logs show exactly what was attempted

3. Safe SQL assistant

Who this is for

• analytics engineers
• database engineers
• backend developers exploring schemas or read-only query workflows

Problem

You want SQL assistance without giving the model silent power to mutate or destroy schemas.

Recommended policy

Use ../examples/ai-safe-sql.ymlFile.

What success looks like

• read-oriented query workflows can continue
• DROP, TRUNCATE, ALTER, and destructive write patterns are blocked
• looped or repeated requests are rate-limited

4. Shared team policy for AI-enabled repos

Who this is for

• engineering teams experimenting with MCP
• repos that want consistent agent boundaries
• maintainers who want to reduce “works on my machine” policy drift

Recommended setup

1. install SecureMCP-Lite as a dev dependency
2. commit secure-mcp.yml
3. commit one client config example, or document a shared npm run mcp:repo-guard script

What success looks like

• new contributors do not have to invent their own local guardrails
• the repo documents its intended agent safety posture
• dangerous defaults are narrowed without forking the target MCP server