AI Engineering Academy · Lektion

Zugriff von Agents auf Tools absichern

Zugriff von Agents auf Tools absichern ist eine kostenlose AI Engineering Academy-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AI Engineering Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

The Tool Access Security Problem

When you give an AI agent a tool, you give it the ability to take real-world actions. A tool that sends emails, runs SQL queries, calls payment APIs, or modifies files can cause significant harm if the agent is compromised by a prompt injection or simply makes a mistake. Securing agentic tool access means designing your tool layer so the damage from any individual tool use is bounded, auditable, and reversible where possible.

The Principle of Least Privilege

Apply the principle of least privilege to every tool: give the agent the minimum access necessary to complete its assigned task, and nothing more. If the agent needs to read customer records, give it a read-only database connection — not the full admin connection you use for maintenance. If it sends notifications, scope its API key to the notification endpoint only. Least privilege limits the blast radius of any security incident.

from enum import Enum
from dataclasses import dataclass

class Permission(Enum):
    READ_CUSTOMER_PROFILE = 'read_customer_profile'
    SEND_NOTIFICATION = 'send_notification'
    READ_ORDER_HISTORY = 'read_order_history'
    WRITE_CUSTOMER_PROFILE = 'write_customer_profile'  # higher privilege
    PROCESS_REFUND = 'process_refund'                  # highest risk

@dataclass
class AgentIdentity:
    agent_id: str
    allowed_permissions: set[Permission]

# Support chat agent: read-only + send notification only
SUPPORT_AGENT = AgentIdentity(
    agent_id='support-agent-v1',
    allowed_permissions={
        Permission.READ_CUSTOMER_PROFILE,
        Permission.READ_ORDER_HISTORY,
        Permission.SEND_NOTIFICATION  # can notify, but NOT write or refund
    }
)

# NOT: give every agent all permissions for convenience

Permission-Gated Tool Execution

Enforce least privilege at the execution layer, not just at the design layer. Every tool call must pass through a permission check that verifies the calling agent has the required permission for that specific action. This cannot be bypassed by the agent or a prompt injection because it is enforced in code, not in the LLM's prompt.

class ToolGateway:
    def __init__(self, agent: AgentIdentity):
        self.agent = agent
        self.audit_log = []

    def execute_tool(self, tool_name: str, required_permission: Permission, tool_fn, **kwargs) -> dict:
        # Permission check - enforced in code, not in the LLM prompt
        if required_permission not in self.agent.allowed_permissions:
            self.log_denied(tool_name, required_permission, kwargs)
            raise PermissionError(
                f'Agent {self.agent.agent_id} does not have permission: {required_permission.value}'
            )
        
        # Execute tool
        result = tool_fn(**kwargs)
        self.log_allowed(tool_name, kwargs, result)
        return result

    def log_denied(self, tool: str, permission: Permission, args: dict):
        entry = {'type': 'DENIED', 'agent': self.agent.agent_id, 'tool': tool, 'permission': permission.value, 'args': args}
        self.audit_log.append(entry)
        print(f'SECURITY: Permission denied - {entry}')

    def log_allowed(self, tool: str, args: dict, result):
        entry = {'type': 'ALLOWED', 'agent': self.agent.agent_id, 'tool': tool, 'args': args}
        self.audit_log.append(entry)

gateway = ToolGateway(SUPPORT_AGENT)

# This will succeed (agent has READ permission)
gateway.execute_tool('read_profile', Permission.READ_CUSTOMER_PROFILE, read_customer_profile, user_id='123')

# This will raise PermissionError (agent lacks PROCESS_REFUND permission)
gateway.execute_tool('process_refund', Permission.PROCESS_REFUND, process_refund, order_id='456', amount=50.00)

Confirmation Steps for Destructive Actions

Some actions are irreversible or high-impact: deleting records, sending bulk emails, processing financial transactions. Require explicit human confirmation before the agent executes any such action. The agent proposes the action (what it wants to do and why), a human approves or rejects it, and only then does execution proceed. This confirmation gate is the single most effective defense against agent errors and injection-driven abuse.

HIGH_RISK_ACTIONS = {
    'delete_customer_record',
    'send_bulk_email',
    'process_refund_over_100',
    'deploy_code',
    'revoke_user_access'
}

def execute_with_confirmation(tool_name: str, tool_args: dict, agent_reasoning: str) -> dict:
    if tool_name in HIGH_RISK_ACTIONS:
        # Pause and request human approval
        approval_request = {
            'action': tool_name,
            'arguments': tool_args,
            'agent_reasoning': agent_reasoning,
            'risk_level': 'HIGH'
        }
        approval = request_human_approval(approval_request)  # blocks until human responds
        
        if not approval.approved:
            return {'status': 'rejected', 'reason': approval.rejection_reason}
        
        # Log the approval for audit trail
        log_approval(tool_name, tool_args, approved_by=approval.approver_id)
    
    # Execute only after confirmation
    return execute_tool(tool_name, **tool_args)

Tool Scoping: Time, User, and Data Boundaries

Beyond permission types, scope tool access along three dimensions. Time boundaries: API keys or tokens that expire after the agent's session ends. User boundaries: an agent helping user A should never access user B's data, even if the agent is instructed to. Data boundaries: a customer support agent should access only the data of the customer it is currently helping, not all customers. Implement these boundaries in your tool implementations, not in agent prompts.

class ScopedCustomerTool:
    def __init__(self, current_user_id: str, session_token: str):
        self.user_id = current_user_id  # agent can only access THIS user's data
        self.token = session_token       # expires at end of session

    def get_customer_profile(self) -> dict:
        # Hardcoded to current user - agent cannot change this via prompt
        return db.query(
            'SELECT * FROM customers WHERE id = %s',
            (self.user_id,)  # parameterized, always this user's ID only
        )

    def get_order_history(self, limit: int = 10) -> list:
        # Even if the agent says 'get orders for user 999', it gets self.user_id
        return db.query(
            'SELECT * FROM orders WHERE customer_id = %s ORDER BY date DESC LIMIT %s',
            (self.user_id, min(limit, 50))  # cap limit too
        )

# Inject scoped tool into agent - cannot be overridden by prompt
def create_support_agent(user_id: str, session_token: str):
    scoped_tools = ScopedCustomerTool(user_id, session_token)
    return AgentExecutor(llm=llm, tools=[scoped_tools.get_customer_profile, scoped_tools.get_order_history])

Input Validation on Tool Arguments

Agents generate tool arguments as text. Before executing any tool, validate all arguments against a strict schema. This prevents: SQL injection through tool parameters, path traversal attacks (agent passing '../../../etc/passwd' as a file path), SSRF attacks (agent passing an internal service URL as a 'remote URL' parameter), and integer overflow or out-of-range values that could cause unexpected behavior.

from pydantic import BaseModel, validator, constr, confloat
import re

class SendEmailArgs(BaseModel):
    to: str
    subject: constr(max_length=200)
    body: constr(max_length=10000)

    @validator('to')
    def must_be_company_email(cls, v):
        if not re.match(r'^[^@]+@(?:yourcorp\.com|partner\.com)$', v):
            raise ValueError('Email must be sent to yourcorp.com or partner.com domains only')
        return v

class ReadFileArgs(BaseModel):
    filename: constr(pattern=r'^[a-zA-Z0-9_\-\.]+$')  # alphanumeric only, no path traversal

    @validator('filename')
    def no_parent_directory(cls, v):
        if '..' in v or '/' in v or '\\' in v:
            raise ValueError('Path traversal detected')
        return v

# Validate before execution
def validated_send_email(args_dict: dict) -> dict:
    args = SendEmailArgs(**args_dict)  # raises ValueError on invalid input
    return send_email(args.to, args.subject, args.body)

Immutable Audit Logging

Every tool call made by an agent must be logged in an immutable audit log. The log entry must include: the agent ID and session ID, the tool name and all arguments, the return value, the timestamp, and the agent's stated reasoning for making the call. Immutable means the agent (or an attacker) cannot delete or modify log entries. Use append-only storage (cloud logging services, write-once databases, or WORM storage).

import hashlib
import json
import time

class ImmutableAuditLog:
    def __init__(self, log_backend):
        self.backend = log_backend  # e.g., CloudWatch, BigQuery, or append-only file
        self.previous_hash = '0' * 64  # genesis hash

    def record(self, agent_id: str, tool_name: str, args: dict, result, reasoning: str):
        entry = {
            'agent_id': agent_id,
            'tool': tool_name,
            'args': args,
            'result_summary': str(result)[:500],  # truncate large results
            'reasoning': reasoning[:1000],
            'timestamp': time.time(),
            'previous_hash': self.previous_hash  # chain entries like a blockchain
        }
        
        entry_json = json.dumps(entry, sort_keys=True)
        entry['hash'] = hashlib.sha256(entry_json.encode()).hexdigest()
        
        self.backend.append(entry)  # append-only, never update
        self.previous_hash = entry['hash']
        
        return entry['hash']

Detecting Anomalous Agent Behavior

Even with permission gates and audit logs, watch for anomalous behavior patterns that suggest an agent has been compromised or is behaving unexpectedly. Anomaly signals include: a support agent suddenly calling tools it has never called before, an unusual spike in tool call frequency from one agent, arguments that differ from the norm in suspicious ways (unusually long strings, strange character sequences), or calls that happen at unusual hours.

from collections import Counter

class AgentBehaviorMonitor:
    def __init__(self):
        self.tool_call_counts = Counter()  # tracks historical tool usage
        self.arg_length_history = {}       # tracks typical argument lengths

    def record_and_check(self, agent_id: str, tool_name: str, args: dict) -> list[str]:
        key = f'{agent_id}:{tool_name}'
        anomalies = []
        
        self.tool_call_counts[key] += 1
        
        # Flag tools never called before by this agent
        if self.tool_call_counts[key] == 1 and tool_name not in COMMON_TOOLS:
            anomalies.append(f'First time agent {agent_id} called unusual tool: {tool_name}')
        
        # Flag unusually long arguments (potential injection payload)
        total_arg_length = sum(len(str(v)) for v in args.values())
        if tool_name not in self.arg_length_history:
            self.arg_length_history[tool_name] = []
        self.arg_length_history[tool_name].append(total_arg_length)
        
        if len(self.arg_length_history[tool_name]) > 10:
            avg = sum(self.arg_length_history[tool_name]) / len(self.arg_length_history[tool_name])
            if total_arg_length > avg * 5:
                anomalies.append(f'Unusually long arguments for {tool_name}: {total_arg_length} chars (avg: {avg:.0f})')
        
        return anomalies

Token Expiry and Session Scoping

Agent sessions should have a defined lifespan. Issue short-lived tokens or credentials to the agent when a session starts, and revoke them when the session ends. If an agent's session is compromised mid-execution, an attacker's ability to exploit the compromised session is bounded by the token's expiry. Session scoping also ensures that a single compromised agent cannot be used for follow-up attacks days later.

import secrets
import time

class SessionTokenManager:
    def __init__(self, ttl_seconds=3600):
        self.tokens = {}  # token -> (agent_id, user_id, expires_at)
        self.ttl = ttl_seconds

    def issue_token(self, agent_id: str, user_id: str) -> str:
        token = secrets.token_urlsafe(32)
        expires_at = time.time() + self.ttl
        self.tokens[token] = (agent_id, user_id, expires_at)
        return token

    def validate_token(self, token: str) -> dict | None:
        if token not in self.tokens:
            return None
        agent_id, user_id, expires_at = self.tokens[token]
        if time.time() > expires_at:
            del self.tokens[token]  # clean up expired token
            return None
        return {'agent_id': agent_id, 'user_id': user_id}

    def revoke_token(self, token: str):
        self.tokens.pop(token, None)

token_manager = SessionTokenManager(ttl_seconds=1800)  # 30-minute sessions

Testing Tool Security

Test your tool security layer by simulating attacks: try calling a restricted tool with an unauthorized agent, provide path traversal arguments, inject instruction strings into tool parameters, and attempt to call tools with expired tokens. A comprehensive tool security test suite should cover all permission boundaries, all validation rules, and all anomaly detection triggers.

Designing for Reversibility

Where possible, design tools to be reversible or staged. Instead of immediately deleting a record, mark it as deleted with a tombstone so it can be restored. Instead of sending an email immediately, put it in a 'pending send' queue that executes after a 5-minute review window. Stage financial transactions with a hold before settlement. Reversibility does not eliminate the security risk but dramatically reduces the impact of successful attacks.

Quick Check

Test your understanding of securing agentic tool access from this lesson.

Lesson Recap

In this lesson you learned: the principle of least privilege limits tool permissions to what each agent role actually needs, code-level permission gates enforce these permissions in a way that cannot be bypassed by prompt injection, and human confirmation steps for high-risk actions provide a final safety net before irreversible operations execute. Next up we run a structured red-team exercise on LLM applications.

Häufig gestellte Fragen

Ist die Lektion „Zugriff von Agents auf Tools absichern“ kostenlos?

Ja — der vollständige Text von „Zugriff von Agents auf Tools absichern“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AI Engineering Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Zugriff von Agents auf Tools absichern“?

Wenden Sie das Prinzip der geringsten Berechtigungen auf die Tool-Berechtigungen von Agents an, implementieren Sie Bestätigungsschritte vor destruktiven Aktionen und prüfen Sie Agent-Aktionsprotokoll… Du übst AI Engineering Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um AI Engineering Academy zu starten?

Keine Vorkenntnisse erforderlich. AI Engineering Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „Zugriff von Agents auf Tools absichern“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser AI Engineering Academy-Lektion Code schreiben und ausführen?

Ja. Jede AI Engineering Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Taxonomie von Prompt-Injection-Angriffen
Schutz vor Injection in RAG-Systemen
Zugriff von Agents auf Tools absichern
Ihre LLM-Anwendung einem Red Teaming unterziehen

← Zurück zu AI Engineering Academy