Command injection and input validation: protecting tools that perform actions

Introduction

A tool can look like a simple function and end up running a process, querying a database or modifying an external resource. If the input is concatenated into a command or interpreted without controls, an injection risk appears. The cause lies in the tool’s design and implementation, not in MCP as a protocol.

Validate the meaning, not just the format

Define strict schemas: types, lengths, formats and allowed fields. Reject unexpected values with clear errors. But an input that matches the schema may still be outside authorization: also check that the user can operate on that resource and that the tool allows that action in its context.

When you need to invoke a process, use structured APIs or execution with separate arguments instead of concatenating data into a shell string. Avoid interpreters when they are not needed. Use allowed paths, controlled working directories and an isolated environment with minimal permissions.

For operations with effects, limit the action to a specific task; do not turn free-form model instructions into arbitrary commands. Apply limits on time, output and resources. The service receiving the request must validate its own authorization: client-side validation or an interface confirmation is not enough.

Testing and safe errors

Test boundaries, missing fields, wrong types and unexpected inputs with harmless test data. Check that a rejected operation leaves no partial effects. Keep error messages useful for diagnosis without returning secrets, internal paths or unnecessary details.

Conclusion

The defense combines semantic validation, authorization, safe APIs, isolation and negative testing. The safest option is usually a narrow, predefined operation, not a general interpreter connected to the model.