모든 항목 검증 및 정제하기

Every argument the model passes to a tool is untrusted input. The model may be honest, but its arguments can be shaped by injected text, so verify them. 🔎

Check shape, type, and range before a tool does anything real. Validation at the door turns a vague bad call into a clear, safe rejection.

Type hints and Pydantic models reject malformed arguments before your code runs. This input must be a positive int, so a string or a negative value is refused early.

Cap sizes, lengths, and counts. A limit field on a query keeps the model from asking for a million rows and turning one call into a denial of service.

Sanitizing means making input safe for where it lands. A value safe in a log can be dangerous in a shell, a SQL string, or a file path.

String-concatenated SQL invites injection. Use parameterized queries so the database treats model input strictly as a value, never as executable code.

If a tool runs a command, never paste arguments into a shell string. Pass an argument list and avoid shell parsing so input cannot smuggle in extra commands.

For file tools, resolve the path to its canonical form and confirm it stays inside your allowed root. Reject anything with a path traversal like dot-dot.

When input does not pass a check, stop and return a clear error. Failing closed beats guessing, because a wrong guess can be exactly what an attacker wants.

Data your tool returns can carry injected instructions onward. Where it matters, label or escape fetched content so the model treats it as data, not orders.

Check input as it enters your tool and again before it hits a database, file, or API. Each boundary is a fresh chance to catch something unsafe.

Which choice best protects a SQL query from injection?

Treat all tool inputs as untrusted: validate types and ranges, sanitize for the destination, confine paths, and fail closed. Distrust the input. ✅