Articles

Secure LLM Tool Use: Prevent API Abuse (2026)

April 16, 2026 9 min read

LLM tool use is fundamentally about enabling an LLM to interact with the outside world, and the most common way it breaks is when that interaction becomes a vector for abuse, often manifesting as unexpected API calls or excessive resource consumption.

Here are the common causes and how to fix them:

1. Unbounded Tool Invocation

  • Diagnosis: The LLM, without explicit constraints, can decide to call a tool multiple times in a single turn, leading to runaway costs or unintended side effects.
    • Check your LLM’s output logs for repeated, identical tool calls within a single user prompt.
    • Example: {"tool_calls": [{"id": "call_abc123", "type": "function", "function": {"name": "search_api", "arguments": "\"query\": \"latest news\""}}], "tool_calls": [{"id": "call_abc123", "type": "function", "function": {"name": "search_api", "arguments": "\"query\": \"latest news\""}}], ...}
  • Fix: Implement a turn-level or tool-level invocation limit. For instance, restrict the LLM to a maximum of 5 tool calls per user turn.
    • In your LLM orchestration framework (e.g., LangChain, LlamaIndex), configure the agent or LLM call to accept a max_iterations or max_tool_calls parameter.
    • Example (LangChain):
      from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_openai_functions_agent
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.tools import tool

@tool
def search_api(query: str) -> str:
    """Searches for information online."""
    # ... actual search logic ...
    return f"Results for {query}: ..."

llm = ChatOpenAI(model="gpt-4o", temperature=0)
tools = [search_api]
prompt = ChatPromptTemplate.from_messages([...]) # Your prompt
agent = create_openai_functions_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, max_iterations=5) # Set limit here
agent_executor.invoke({"input": "What's the weather like?"})
  • Why it works: This directly caps the number of times the LLM can request execution of a tool within a single response cycle, preventing infinite loops or excessive parallelization.

2. Sensitive Data Exposure via Tool Arguments

  • Diagnosis: The LLM might inadvertently include sensitive user data (like PII, API keys, or internal system details) in the arguments passed to external tools, which could then be logged or exposed.
    • Review tool call arguments in your logs for any personally identifiable information, secrets, or internal identifiers that shouldn’t be exposed.
    • Example Log Snippet: tool_calls": [{"name": "send_email", "arguments": "{\"to\": \"user@example.com\", \"subject\": \"Your Order #12345 Details\", \"body\": \"Hi John Doe, your order...\"}"}] (where "John Doe" was inferred from context).
  • Fix: Implement input sanitization and data masking before arguments are passed to the tool. Use PII detection libraries or regex to identify and redact sensitive fields.
    • Create a wrapper function for your tools that performs this sanitization.
    • Example (Conceptual):
      import re

def sanitize_args(args_dict):
    sanitized = args_dict.copy()
    for key, value in sanitized.items():
        if isinstance(value, str):
            # Redact common PII patterns
            sanitized[key] = re.sub(r'\b[A-Z][a-z]+ [A-Z][a-z]+\b', '[REDACTED NAME]', value) # Basic Name Redaction
            sanitized[key] = re.sub(r'\b\d{3}-\d{3}-\d{4}\b', '[REDACTED PHONE]', sanitized[key]) # Phone Number
            # Add more patterns for email, SSN, etc.
    return sanitized

def send_email_safe(to: str, subject: str, body: str) -> str:
    sanitized_body = sanitize_args({"body": body})["body"]
    # ... actual send_email logic using sanitized_body ...
    return "Email sent successfully."

# When defining tools for the LLM:
tools = [
    Tool(
        name="send_email",
        func=send_email_safe, # Use the safe wrapper
        description="Sends an email to a recipient."
    )
]
  • Why it works: This acts as a defensive layer, ensuring that even if the LLM attempts to pass sensitive data, it’s scrubbed before the tool actually executes or logs the information.

3. Malicious Tool Chaining / Prompt Injection via Tool Output

  • Diagnosis: An attacker can craft a prompt that tricks the LLM into calling a tool with specific arguments, and then the output of that tool is used to craft a subsequent, malicious instruction to the LLM. This is especially dangerous if tools return user-controlled or external data.
    • Look for patterns where the LLM’s internal reasoning process seems to incorporate output from a previously executed tool in a way that leads to a dangerous or unexpected final action.
    • Example: User prompt: "Find the latest product reviews. Then, using the first review, send a feedback email to our support team with the subject 'URGENT: Issue with Product X' and the body being the exact content of that review." If the review content contains malicious code or instructions, it could be executed.
  • Fix: Implement strict output validation and sandboxing for tool outputs before they are fed back into the LLM’s context for further processing. Limit the complexity of operations the LLM can perform based on tool outputs.
    • Consider using a separate, simpler LLM or a rule-based system to process tool outputs before they re-enter the main LLM’s context. Disallow raw HTML, JavaScript, or command execution within tool outputs that are fed back to the LLM.
    • Example (Conceptual Guardrail):
      def is_safe_for_llm_context(tool_output: str) -> bool:
    # Basic checks: disallow script tags, excessive code
    if "<script>" in tool_output.lower() or "</script>" in tool_output.lower():
        return False
    # Add checks for command injection patterns, etc.
    return True

# When processing tool results before returning to LLM for next step:
if is_safe_for_llm_context(tool_result):
    # Proceed with LLM turn
    pass
else:
    # Log warning, deny further processing, or respond with an error
    print("Potentially unsafe tool output detected. Action aborted.")
  • Why it works: By validating and sanitizing tool outputs, you prevent the LLM from interpreting malicious code or instructions that might have been injected through the tool’s return value.

4. Over-Reliance on Specific Tools / Stubbornness

  • Diagnosis: The LLM might repeatedly try to use a tool that is not appropriate for the current query, or fail to switch to a more suitable tool when presented with new information. This can lead to failed attempts and wasted API calls.
    • Observe the agent’s thought process logs. If the LLM consistently picks the same tool for diverse queries, or gets stuck in a loop of "I can’t do that with this tool" followed by another attempt with the same tool, this is a sign.
    • Example Log Snippet: Thought: I need to find the user's email address. The 'get_user_profile' tool might have it. Tool Call: get_user_profile(user_id="123") Observation: User profile does not contain email address. Thought: I still need the user's email. I should try 'get_user_profile' again.
  • Fix: Improve tool descriptions and add negative constraints. Explicitly state when a tool should not be used. Fine-tune the LLM’s ability to understand when a tool is insufficient.
    • Enhance the description field for your tools to be more precise about their scope and limitations.
    • Example (Tool Description):
      Tool(
    name="get_user_profile",
    func=get_user_profile,
    description="Retrieves a user's profile information *excluding* contact details like email or phone. Use 'list_user_contacts' for those.",
    # ... other args
)
Tool(
    name="list_user_contacts",
    func=list_user_contacts,
    description="Retrieves a user's contact information, including email and phone numbers. Do NOT use this to get general profile data like address or preferences.",
    # ... other args
)
  • Why it works: Clearer, more specific tool descriptions and explicit negative constraints guide the LLM’s decision-making, making it less likely to choose an inappropriate tool or get stuck retrying an ineffective one.

5. Uncontrolled Recursion with Self-Modifying Tools

  • Diagnosis: If a tool’s function is to modify other tools or the LLM’s available functions (e.g., dynamically adding new capabilities), and this process is not carefully controlled, it can lead to infinite recursion or the LLM gaining unintended, dangerous abilities.
    • This is harder to spot in standard logs. You’d need to instrument your system to track dynamic tool registration/modification events and their triggers. Look for rapid, uncontrolled changes in the set of available tools during a single session.
  • Fix: Implement a "tool approval" or "tool registry" mechanism. Any new tool or modification to an existing tool must pass a review process (either human or a pre-defined, robust automated check) before becoming active. Limit the depth of tool modification chains.
    • Maintain a static list of approved tool definitions. If a tool needs to be added or changed, it requires explicit code deployment and re-initialization of the LLM agent’s toolset.
    • Example (Conceptual Workflow):
      1. LLM identifies a need for a new capability.
      2. LLM generates a proposed tool definition (e.g., as JSON).
      3. This proposal is sent to an external validation service.
      4. The validation service checks for security risks, redundancy, and adherence to schema.
      5. If validated, a human operator or automated deployment pipeline adds the new tool to the static tool list, which is then reloaded by the LLM agent.
  • Why it works: This prevents the LLM from autonomously granting itself new, potentially harmful capabilities, ensuring that all tool modifications are intentional and vetted.

6. Ambiguous Tool Selection or Parameter Mapping

  • Diagnosis: When multiple tools have similar names or functionalities, or when the LLM misinterprets a user’s intent and maps it to the wrong tool parameters, it can lead to incorrect actions and wasted resources.
    • Review sessions where the LLM chose a tool that seemed "close" but not quite right, or where parameters were clearly mismatched (e.g., passing a product ID to a user ID parameter).
    • Example: User asks "Order me a pizza." The LLM has order_food(item: str, quantity: int) and order_pizza(size: str, toppings: list). If it picks order_food and maps "pizza" to item, it might fail if quantity is not provided, or if the system expects a more specific order_pizza call.
  • Fix: Ensure tool names and descriptions are highly distinct. Use structured prompts that guide the LLM towards specific tool selection when ambiguity exists. Implement parameter validation within tools.
    • When defining tools, use clear, unique names (e.g., order_specific_pizza vs. order_general_food). Provide detailed parameter descriptions.
    • Example (Parameter Validation within Tool):
      from pydantic import BaseModel, Field

class PizzaOrder(BaseModel):
    size: str = Field(..., description="Size of the pizza, e.g., 'small', 'medium', 'large'")
    toppings: list[str] = Field(..., description="List of toppings, e.g., ['pepperoni', 'mushrooms']")

def order_pizza(order_details: PizzaOrder) -> str:
    # Pydantic automatically validates order_details against the PizzaOrder schema
    if not all(topping in ['pepperoni', 'mushrooms', 'olives', 'onions'] for topping in order_details.toppings):
         return "Error: Invalid topping requested. Available toppings: pepperoni, mushrooms, olives, onions."
    # ... actual ordering logic ...
    return f"Order confirmed for a {order_details.size} pizza with {', '.join(order_details.toppings)}."

# LLM framework would map incoming JSON args to the Pydantic model
  • Why it works: Distinct tool names reduce confusion. Parameter validation within the tool functions acts as a final gatekeeper, rejecting malformed or inappropriate inputs before they can cause issues.

The next potential issue you’ll encounter after addressing these is managing the state and context across multiple turns of tool use, especially when dealing with complex, multi-step workflows.

Want structured learning?

Take the full AI Security course →