최소 권한의 도구 접근

Least privilege means each tool gets only the permissions its job requires, and nothing more. If a tool is tricked, the blast radius stays small. 🔒

A tool that reads one report folder should not be able to touch the whole disk. Give it the smallest scope that still gets the work done, then stop there.

Split read and write into separate tools when you can. A read-only tool that gets injected can leak data, but it cannot quietly change or delete anything.

Privilege also lives in the token your server holds. Use a database role or API key scoped to exactly the operations needed, so a slip cannot reach unscoped resources.

This tool can only look up an order, never modify one. The function body defines the ceiling on what the model can do through it.

One run_anything tool that executes arbitrary code or SQL hands the model total control. Prefer many narrow tools with fixed, predictable behavior instead.

Decide what is permitted, not what is forbidden. An allowlist of safe operations is far easier to reason about than trying to enumerate every dangerous one.

If a tool reads files, pin it to one base directory and reject paths that escape it. A bounded root stops a tool from wandering into system files.

Keep low-risk lookups apart from high-risk actions. You can then apply stricter checks and confirmation to only the sensitive tools that truly need them.

The server, not the model, decides who may do what. Check the caller's identity before acting so a tool cannot reach data outside that user's permissions.

Start every new tool from the assumption that it can do nothing, then grant exactly what it needs. A default-deny stance keeps accidental power from creeping in.

Pick the design that best follows least privilege.

Give each tool the smallest scope, split read from write, scope your credentials, and default to deny. Least privilege keeps any single mistake contained. ✅