Tool Execution: How Agents Run Functions Safely

The Execution Pipeline

Tool execution follows a pipeline that transforms a model-generated intent into a real operation. The pipeline has five stages: parsing, validation, authorization, execution, and result formatting. Each stage serves as a checkpoint that can reject, modify, or approve the operation before it proceeds to the next stage. This layered approach ensures that no tool call reaches the underlying system without passing through multiple safety checks.

Parsing extracts the function name and arguments from the model response. This step handles provider-specific response formats and produces a normalized internal representation. A well-designed parsing layer can handle malformed JSON gracefully, logging the error and returning a descriptive error message to the model rather than crashing the application.

Validation checks the parsed arguments against the expected schema: correct data types, required fields present, values within acceptable ranges, string formats matching expected patterns. Schema validation is the first line of defense against invalid tool calls. Applications should use a JSON Schema validator library rather than implementing validation logic manually, because manual validation invariably misses edge cases.

Authorization determines whether the current user, session, or agent has permission to execute the requested function with the specified arguments. A customer support agent might have permission to view orders but not to modify them. An agent processing a specific user request should only access that user data, not other users. Authorization checks enforce the business rules and security policies that the model has no knowledge of.

Execution invokes the actual function with the validated, authorized arguments. This is the step where side effects occur, and it should be instrumented with logging, metrics, and tracing. Every execution should record what function was called, with what arguments, by which agent, at what time, and what result was produced. This audit trail is essential for debugging, compliance, and security monitoring.

Input Validation Strategies

Input validation for tool calls must be as rigorous as validation for user input, because model-generated arguments can be manipulated through prompt injection. The model is not a trusted source of input. It is a mediator between potentially adversarial user input and your application functions. Arguments should be validated for type correctness, range constraints, format compliance, and semantic validity.

Type validation ensures that string parameters contain strings, numeric parameters contain numbers, and boolean parameters contain booleans. JSON Schema validators handle this automatically. Format validation goes further, checking that string values match expected patterns: email addresses match email format, dates are valid dates in the expected format, URLs are well-formed, and identifiers exist in the expected systems.

Range validation prevents out-of-bounds values that could cause unexpected behavior. A "limit" parameter that accepts any integer might receive a value of 1,000,000, causing the underlying database query to return an enormous result set. Setting an explicit maximum (like 100) in both the schema and the validation layer prevents this. Range validation should apply to string lengths, array sizes, and numeric values.

Semantic validation checks whether the arguments make sense in combination. A date range where the start date is after the end date is syntactically valid but semantically wrong. A search query that contains SQL injection patterns is a valid string but a potential attack. Semantic validation requires application-specific logic that goes beyond what JSON Schema can express.

Sandboxing and Isolation

The execution environment for tool calls should be isolated from the rest of the application to limit the blast radius of failures and security breaches. Sandboxing techniques vary by language and platform, but the principle is consistent: tool execution should have the minimum permissions needed to perform its specific operation, with no ability to access or modify resources outside its scope.

Process-level isolation runs each tool execution in a separate process with restricted system access. This prevents a malfunctioning or compromised tool from affecting other tools, accessing memory it should not, or consuming unbounded system resources. Container-based isolation goes further, running each tool in its own container with controlled network access, filesystem mounts, and resource limits.

Network isolation controls which external services each tool can communicate with. A tool that queries a specific database should only be able to reach that database, not arbitrary network endpoints. A tool that calls a specific API should only be able to communicate with that API domain. Network policies prevent a compromised tool from exfiltrating data to unauthorized destinations.

Resource limits prevent individual tool executions from consuming excessive CPU, memory, or disk space. A poorly written or malicious tool call should not be able to starve the system of resources or cause an out-of-memory crash. Limits on execution time, memory allocation, and output size keep each execution bounded and predictable.

Output Formatting and Size Management

The result of a tool execution must be formatted for the model to interpret effectively. Raw function return values often contain more data than the model needs or data in formats that are difficult for the model to parse. Good result formatting balances completeness (including all relevant information) with conciseness (excluding unnecessary noise that consumes context window tokens).

JSON is the preferred format for structured tool results because models parse it accurately and can reference specific fields in their responses. Plain text is appropriate for simple results like status messages or short descriptions. Large datasets should be summarized, paginated, or truncated to avoid overwhelming the model context window. A database query that returns 1,000 rows should be limited to the most relevant 10 to 20 rows with a note indicating how many total results exist.

Error results should follow a consistent format that the model can interpret and act on. A standard error format might include an error code, a human-readable message, and optionally a suggestion for what the model should do next. Consistency across all tools helps the model develop reliable error handling behavior.

Timeout and Circuit Breaker Patterns

Every tool execution should have a timeout that prevents indefinite blocking. External API calls can hang due to network issues, service outages, or resource contention. Without a timeout, a single hanging tool call blocks the entire agent loop and wastes resources. Timeouts should be set based on the expected duration of each tool: a fast key-value lookup might have a 5-second timeout, while a complex search operation might have a 30-second timeout.

Circuit breakers prevent repeated calls to a failing service. When a tool fails multiple times in succession, the circuit breaker "opens" and immediately returns an error for subsequent calls without attempting execution. After a cooldown period, the circuit breaker allows a test call through to check if the service has recovered. This pattern prevents cascade failures where a failing dependency causes the entire agent system to degrade.

Bulkhead isolation limits the number of concurrent executions for each tool type. A tool that calls a rate-limited API should have a concurrency limit that matches the API rate limit. A tool that queries a database should limit concurrent connections to avoid overwhelming the database. Bulkheads ensure that heavy usage of one tool does not consume all available resources and starve other tools.