Richtliniendurchsetzung für Agentenaktionen
Richtlinienprüfungen vor Aktionen, Allow- und Denylists sowie dynamische Richtlinienregeln.
Richtliniendurchsetzung für Agentenaktionen ist eine kostenlose AI Agents-Lektion auf CoddyKit. Dies ist Lektion 2 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 Agents-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AI Agents-Kurs umfasst insgesamt 4 Lektionen.
Was ist Policy-Durchsetzung für Agenten?
Policy-Durchsetzung ist das Laufzeit-Gate, das vor jeder Agentenaktion ausgeführt wird, um zu entscheiden, ob die Aktion zulässig ist. Ohne dieses Gate ist die einzige Einschränkung des Agenten das Befolgen von Anweisungen durch das LLM – und dieses kann umgangen oder falsch interpretiert werden.
Die Durchsetzung muss außerhalb des LLM in Ihrer Infrastruktur erfolgen.
Das Muster der Prüfung vor der Aktion
Rufen Sie vor der Ausführung eines beliebigen Tools can_agent_do(action, context) auf. Diese Funktion ist die zentrale Durchsetzungsstelle – jeder Pfad zur Ausführung einer Aktion führt über sie.
def can_agent_do(action: str, context: dict) -> tuple[bool, str]:
'''
Returns (allowed: bool, reason: str).
Context includes: user_id, agent_id, session_id, parameters, timestamp.
'''
# 1. Check denylist first (fast path for obvious violations)
if action in DENIED_ACTIONS:
return False, f'Action "{action}" is on the global denylist'
# 2. Check allowlist
if action not in ALLOWED_ACTIONS:
return False, f'Action "{action}" is not on the allowlist'
# 3. Context-specific checks
return check_context_policy(action, context)Allowlists und Denylists definieren
Die Allowlist führt jede Aktion auf, die der Agent ausführen darf. Alles, was nicht auf der Liste steht, wird standardmäßig blockiert. Die Denylist bietet eine zusätzliche Sicherheitsmaßnahme für Aktionen, die unabhängig vom Kontext niemals erlaubt sein dürfen.
# Allowlist: tools the agent can use
ALLOWED_ACTIONS = {
'web_search',
'read_file',
'write_file',
'send_email',
'create_calendar_event',
'query_database',
'execute_python_sandbox',
'fetch_url',
'create_ticket'
}
# Denylist: actions that are always blocked, regardless of context
DENIED_ACTIONS = {
'delete_all_records',
'export_entire_database',
'send_mass_email',
'modify_system_config',
'create_admin_user',
'disable_audit_logging'
}
if __name__ == '__main__':
for action in ('web_search', 'send_mass_email'):
print(f"{action}: allowed={action in ALLOWED_ACTIONS} denied={action in DENIED_ACTIONS}")
Kontextspezifische Policy-Prüfungen
Über einfache Allow- und Deny-Listen hinaus hängen Policies häufig vom Kontext ab: Wer ist der Benutzer, welche Rolle hat er, wie spät ist es und auf welche Zielressource wird zugegriffen? Dies sind kontextspezifische Prüfungen.
from datetime import datetime, timezone
def check_context_policy(action: str, context: dict) -> tuple[bool, str]:
user_id = context.get('user_id', '')
params = context.get('parameters', {})
user_role = context.get('user_role', 'user')
# send_email: only agents with email_sender role
if action == 'send_email':
if user_role not in ('email_agent', 'admin'):
return False, f'Role "{user_role}" cannot send emails'
recipient = params.get('to', '')
if not recipient.endswith('@trusted-domain.com'):
return False, 'Email recipient must be in @trusted-domain.com'
# write_file: path restrictions
if action == 'write_file':
path = params.get('path', '')
if not path.startswith('/tmp/') and not path.startswith('/workspace/'):
return False, f'File writes outside /tmp/ and /workspace/ are not allowed'
return True, 'Permitted'
if __name__ == '__main__':
ctx = {'user_id': 'u1', 'user_role': 'user',
'parameters': {'to': 'someone@gmail.com'}}
print('send_email as user:', check_context_policy('send_email', ctx))
ctx2 = {'user_id': 'u1', 'user_role': 'user',
'parameters': {'path': '/etc/passwd'}}
print('write_file outside sandbox:', check_context_policy('write_file', ctx2))
Dynamische Policies aus einer Policy Engine
Fest codierte Policies lassen sich in der Produktion nur schwer aktualisieren. Verwenden Sie eine Policy Engine (wie OPA – Open Policy Agent), um Policies zu bewerten, die als Daten und nicht als Code definiert sind. Policies können aktualisiert werden, ohne den Agenten erneut bereitzustellen.
import requests
OPA_URL = 'http://localhost:8181/v1/data/agent/allow'
def opa_policy_check(action: str, context: dict) -> tuple[bool, str]:
payload = {
'input': {
'action': action,
'user_id': context.get('user_id'),
'role': context.get('user_role', 'user'),
'params': context.get('parameters', {}),
'time_utc': datetime.now(timezone.utc).isoformat()
}
}
try:
resp = requests.post(OPA_URL, json=payload, timeout=0.5)
result = resp.json().get('result', {})
allowed = result.get('allow', False)
reason = result.get('reason', 'Policy decision')
return allowed, reason
except Exception as e:
# Fail closed: deny if policy engine is unreachable
return False, f'Policy engine unavailable: {e}'Fail-closed und Fail-open
Wenn die Policy Engine nicht verfügbar ist, haben Sie zwei Möglichkeiten:
- Fail-closed: Alle Aktionen ablehnen. Sicher, aber der Agent funktioniert nicht mehr.
- Fail-open: Alle Aktionen zulassen. Der Agent arbeitet weiter, aber die Policy wird nicht durchgesetzt.
Bei sicherheitskritischen Agenten sollten Sie immer Fail-closed verwenden. Bei Produktivitätsagenten mit risikoarmen Aktionen kann Fail-open akzeptabel sein.
FAIL_CLOSED = True # Configure per agent
def safe_policy_check(action: str, context: dict) -> tuple[bool, str]:
try:
return can_agent_do(action, context)
except Exception as e:
if FAIL_CLOSED:
return False, f'Policy check failed (fail-closed): {e}'
else:
# Log the failure but allow the action
import logging
logging.warning('Policy check error (fail-open): %s', e)
return True, 'Policy check bypassed due to error (fail-open)'Rate-Limiting für Aktionen
Die Policy-Durchsetzung kann Rate-Limits umfassen: Ein Agent darf beispielsweise E-Mails senden, aber nur 5 pro Sitzung. Wird das Limit überschritten, wird die Aktion abgelehnt.
from collections import defaultdict
import time
action_counts: dict[str, dict[str, int]] = defaultdict(lambda: defaultdict(int))
action_window_start: dict[str, float] = defaultdict(float)
ACTION_RATE_LIMITS = {
'send_email': {'limit': 5, 'window_secs': 3600}, # 5/hour
'write_file': {'limit': 50, 'window_secs': 300},
'web_search': {'limit': 20, 'window_secs': 60}
}
def check_rate_limit(action: str, session_id: str) -> tuple[bool, str]:
limit_config = ACTION_RATE_LIMITS.get(action)
if not limit_config:
return True, 'No rate limit defined'
window = limit_config['window_secs']
now = time.time()
key = f'{session_id}:{action}'
if now - action_window_start[key] > window:
action_counts[key] = defaultdict(int)
action_window_start[key] = now
action_counts[key]['count'] += 1
if action_counts[key]['count'] > limit_config['limit']:
return False, f'Rate limit exceeded: {action} ({limit_config["limit"]}/{window}s)'
return True, 'Within rate limit'
if __name__ == '__main__':
for i in range(6):
allowed, reason = check_rate_limit('send_email', 'session-1')
print(f'After 6 send_email calls: allowed={allowed}, reason={reason}')
Verstöße gegen Policies protokollieren
Jede Ablehnung aufgrund einer Policy muss mit dem vollständigen Kontext protokolliert werden. Diese Protokolle sind die erste Anlaufstelle, wenn Sie unerwartetes Agentenverhalten debuggen oder einen Sicherheitsvorfall untersuchen.
import logging, json, time
policy_logger = logging.getLogger('agent.policy')
def enforced_action(agent_id: str, user_id: str, action: str,
context: dict, audit_log) -> tuple[bool, str]:
allowed, reason = safe_policy_check(action, context)
log_entry = {
'ts': time.time(),
'agent_id': agent_id,
'user_id': user_id,
'action': action,
'allowed': allowed,
'reason': reason,
'params': context.get('parameters', {})
}
if allowed:
policy_logger.info('ALLOWED %s', json.dumps(log_entry))
else:
policy_logger.warning('DENIED %s', json.dumps(log_entry))
audit_log.append(
agent_id, user_id,
f'POLICY_{"ALLOW" if allowed else "DENY"}',
{'action': action},
{'allowed': allowed, 'reason': reason},
context.get('session_id', '')
)
return allowed, reasonRessourcen begrenzen
Auch bei erlaubten Aktionen müssen Sie den Ressourcenbereich einschränken, auf den der Agent zugreifen kann. Ein Agent, der die Dokumente von Benutzer A verarbeitet, darf nicht die Dateien von Benutzer B lesen können, selbst wenn read_file auf der Allowlist steht.
def check_resource_scope(action: str, context: dict) -> tuple[bool, str]:
user_id = context.get('user_id', '')
params = context.get('parameters', {})
if action == 'read_file':
path = params.get('path', '')
# Each user's files must be under their own namespace
if not path.startswith(f'/workspace/{user_id}/'):
return False, (
f'User {user_id} cannot read files outside '
f'/workspace/{user_id}/'
)
if action == 'query_database':
table = params.get('table', '')
allowed_tables = {'products', 'public_docs', f'user_{user_id}_data'}
if table not in allowed_tables:
return False, f'Table "{table}" not in scope for user {user_id}'
return True, 'Resource scope check passed'
if __name__ == '__main__':
ctx = {'user_id': 'u1', 'parameters': {'path': '/workspace/u2/secret.txt'}}
print('Cross-user file read:', check_resource_scope('read_file', ctx))
ctx2 = {'user_id': 'u1', 'parameters': {'path': '/workspace/u1/notes.txt'}}
print('Own file read: ', check_resource_scope('read_file', ctx2))
Policy-Regeln testen
Policy-Regeln sind Code und müssen getestet werden. Schreiben Sie Unit-Tests für jede Regel, um sicherzustellen, dass Ablehnungen und Zulassungen korrekt funktionieren und Randfälle keine unbeabsichtigten Umgehungen der Policy ermöglichen.
def test_policy_rules():
# Denylist blocks unconditionally
ok, msg = can_agent_do('delete_all_records', {'user_role': 'admin'})
assert not ok, 'Denylist should block even for admin'
# Email requires trusted domain
ok, msg = can_agent_do('send_email', {
'user_role': 'email_agent',
'parameters': {'to': 'attacker@evil.com'}
})
assert not ok, 'Should block untrusted email recipient'
# File write outside allowed paths
ok, msg = can_agent_do('write_file', {
'user_role': 'user',
'parameters': {'path': '/etc/crontab'}
})
assert not ok, 'Should block write to /etc/'
print('All policy tests passed')
test_policy_rules()Policy-Entscheidungen zwischenspeichern
Wenn die Policy Engine bei jeder einzelnen Aktion aufgerufen wird, erhöht dies die Latenz, insbesondere bei Verwendung eines externen OPA-Dienstes. Zwischenspeichern Sie aktuelle Entscheidungen für Paare aus (action, context_hash) mit einer kurzen TTL, um die Anzahl der Round-Trips zu reduzieren.
import hashlib, time
policy_cache: dict[str, dict] = {}
POLICY_CACHE_TTL = 10 # seconds — short TTL so policy updates take effect quickly
def cached_policy_check(action: str, context: dict) -> tuple[bool, str]:
ctx_hash = hashlib.md5(
f'{action}:{context.get("user_id")}:{context.get("user_role")}'
.encode()
).hexdigest()
key = f'{action}:{ctx_hash}'
entry = policy_cache.get(key)
if entry and time.time() - entry['ts'] < POLICY_CACHE_TTL:
return entry['result']
result = can_agent_do(action, context)
policy_cache[key] = {'result': result, 'ts': time.time()}
return resultWas ist der „Fail-closed“-Ansatz bei der Policy-Durchsetzung?
Die Entscheidung zwischen Fail-closed und Fail-open ist ein grundlegender Sicherheitskompromiss für jedes System zur Policy-Durchsetzung. Zu wissen, wann welcher Ansatz angemessen ist, gehört zu den zentralen Governance-Konzepten.
Zusammenfassung: Policy-Durchsetzung
Die Policy-Durchsetzung für Agenten verwendet: eine Prüfung vor der Aktion als einziges Gate, Allowlists und Denylists für grundlegende Entscheidungen, kontextspezifische Regeln zur Ressourcenbegrenzung und Rollenprüfung, eine dynamische Policy Engine (OPA) für aktualisierbare Regeln, Rate-Limits pro Aktion und Sitzung sowie standardmäßig Fail-closed für sicherheitskritische Agenten.
Lerne AI Agents mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 60
- Lektionen
- 239
Häufig gestellte Fragen
Ist die Lektion „Richtliniendurchsetzung für Agentenaktionen“ kostenlos?
Ja — der vollständige Text von „Richtliniendurchsetzung für Agentenaktionen“ 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 Agents-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AI Agents-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Richtliniendurchsetzung für Agentenaktionen“?
Richtlinienprüfungen vor Aktionen, Allow- und Denylists sowie dynamische Richtlinienregeln. Du übst AI Agents 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 Agents zu starten?
Keine Vorkenntnisse erforderlich. AI Agents 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 2 von 4.
Wie lange dauert die Lektion „Richtliniendurchsetzung für Agentenaktionen“?
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 Agents-Lektion Code schreiben und ausführen?
Ja. Jede AI Agents-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
- Unveränderliche Aktionsprotokollierung für Agenten
- Richtliniendurchsetzung für Agentenaktionen
- Einhaltung gesetzlicher Vorgaben: GDPR und SOC2
- Freigabestufen mit Human-in-the-Loop