Autonomous Agent
Tool-Calling Hijacks:
Preventing Silent Privilege Escalation

The attack surface is not the model. It's the gap between what a user is authorized to do and what the agent's service account is authorized to do.

In virtually every enterprise AI agent deployment, the LLM runs under a service account — and service accounts, by organizational convention, tend to accumulate permissions over time. A developer integrating a new tool adds a permission. A deadline creates pressure to use an admin account "just for now." Six months later, the agent's service account has read access to the production database, write access to the email relay, and execute rights on a shell subprocess — and none of the humans working with the agent have those permissions individually.

The model doesn't know this. It knows only that the tools are available and the task requires them. When an attacker manipulates the agent's context — through any of the injection vectors described in the other posts in this series — they inherit the full capability of that service account without triggering a single authorization check.

// The Permission Inheritance Problem

# What the user requested:
user_intent = "Summarize the Q3 sales report and email it to the team"

# What the agent's service account can actually do:
agent_permissions = {
    "file_system": "READ /var/data/* + WRITE /var/data/*",
    "database":    "SELECT * + INSERT + UPDATE + DELETE",
    "email_relay": "SEND to: ANY external address",
    "shell":       "EXEC with subprocess (no allowlist)",
    "secrets":     "READ /etc/env (includes API keys)"
}

# What the agent NEEDS for this specific task:
required_permissions = {
    "file_system": "READ /var/data/reports/q3_sales.pdf",
    "email_relay": "SEND to: @company.com only"
}

# Gap = attack surface
privilege_gap = agent_permissions - required_permissions
# → DB write, external email, shell exec, secrets access
# → Attacker inherits all of this if they control the task context

// Three Attack Patterns in Production

Pattern 1: Context Window Overflow → Shell Escalation

An attacker who controls any input that reaches the agent's context — a document, a ticket, a web search result — can insert a task that sounds like a system instruction. Because the agent's bash tool has no parameter validation, the injected command executes with full service account rights.

Pattern 2: SQL Injection via Agent Intermediary

Traditional SQL injection defenses — parameterized queries, ORM validation — protect against user input reaching the database. When an LLM agent constructs SQL queries from natural language, it creates a new injection path that bypasses these controls entirely: the model itself becomes the vector.

Pattern 3: Email API as Silent Exfiltration Channel

An agent with access to an email relay API and no outbound domain restrictions represents a permanent, low-noise data exfiltration channel. An attacker who can influence the agent's task context can instruct it to send any data it can access — customer records, internal documents, authentication tokens — to an external address, signed by the legitimate service account.

// OWASP Agentic AI — The Relevant Controls

// The Defense Architecture

// Agent Hardening Checklist

• Audit every tool in your agent's registry and document the minimum required permissions for each legitimate use case
• Replace persistent service account credentials with short-lived, task-scoped tokens rotated per invocation
• Enforce JSON Schema validation on all tool parameters at the middleware layer — before any tool call executes
• Remove bash and raw shell tools from all agents that don't have a documented, specific operational need for them
• Implement recipient domain allowlists on all email relay tools — external send should require explicit approval
• Set up egress network filtering at the OS layer for all agent runtime processes
• Deploy append-only telemetry capturing tool name, arguments, caller identity, and raw response for all tool invocations