Agentic Ventures Wiki

audit-checklist

3 Min. Lesezeit

Audit-Checklist

Aufgeteilt nach Caller-Typ. Vor Live-Gang eines neuen Callers oder bei wiederkehrendem Audit: Liste durchgehen, jeden Punkt mit ✅ / ⚠️ / ❌ markieren.

Typ A — ECS-Service mit LiteLLM-Proxy (Pattern: Open-WebUI VF)

  • Modell-Liste in LiteLLM-Config enthaelt nur die Modelle die User-facing sind (sichtbar im Dropdown). Background-Modelle (Haiku) bleiben in model_list aber sind nicht in DEFAULT_MODELS env.
  • TASK_MODEL + TASK_MODEL_EXTERNAL sind auf das billigste verfuegbare Modell gesetzt (Haiku 4.5, nicht Sonnet). Background-Tasks (Title-Gen, Tag-Gen, Search-Query-Gen, Follow-up-Gen) sind oft 60-70% der Calls.
  • DEFAULT_MODEL_PARAMS.max_tokens ist auf einen sinnvollen Cap gesetzt (z.B. 2000 fuer Chat, nicht 8192).
  • DEFAULT_MODEL_PARAMS.thinking ist {"type":"disabled"} oder budget_tokens <= 500 ausser Extended-Thinking ist explizit gewollt.
  • ENABLE_SEARCH_QUERY_GENERATION ist false wenn Web-Search wenig genutzt wird.
  • BYPASS_WEB_SEARCH_EMBEDDING_AND_RETRIEVAL ist false wenn Web-Search aktiv (sonst gehen Roh-Results in den Prompt).
  • RAG Top-K ≤ 4, Chunk-Size ≤ 500 Tokens.
  • Prompt-Caching konfiguriert UND verifiziert (CloudWatch CacheReadInputTokenCount > 0 nach 24h).
  • Application Inference Profile angelegt + ARN in LiteLLM-Config-model_list[].litellm_params.model.
  • Cost-Allocation-Tags Application, Owner, Environment sind am AIP.

Typ B — Lambda mit boto3 + Bedrock (Pattern: receptionist-brain, daily-briefing, beleg-pipeline)

  • BEDROCK_MODEL_ID env-var ist auf Haiku 4.5 gesetzt (nicht Sonnet), ausser Task braucht explizit Sonnet-Qualitaet.
  • inferenceConfig.maxTokens explizit gesetzt im Code (nicht Default-Wert).
  • inferenceConfig.stopSequences wo strukturierter Output (JSON, Tool-Use).
  • System-Prompt < 2000 Tokens (chars/3.5 fuer DE). Wenn groesser: pruefen ob Komprimierung moeglich.
  • MAX_TOOL_ITERATIONS env-var gesetzt (z.B. 5) damit Tool-Use-Loops nicht endlos laufen.
  • AIP-ARN als modelId statt direkter System-Inference-Profile-ARN.
  • Tool-Use: pro MCP-Tool das gerufen wird, Token-Footprint dokumentiert in intern/capabilities/mcps/<slug>.md.

Typ C — FastAPI/ECS mit eigenem Bedrock-Client (Pattern: a-icking inference-service)

  • Bedrock-Modell-ID explizit als Konstante, nicht Default-Argument irgendwo (siehe bedrock_claude.py CLAUDE_HAIKU_4_5_EU).
  • max_tokens Konstruktor-Default sicher (z.B. 1024).
  • System-Prompt-Generator ist deterministisch / hat keinen Zeitstempel oder Random-Wert (sonst kein Caching moeglich).
  • RAG-Top-K + Chunk-Size in Config, default ⇐ 5 / ⇐ 500 Tokens.
  • Embedding-Modell-Wahl dokumentiert: Titan v2 wenn DE-only, Cohere wenn Cross-Lingual.

Typ D — MCP-Server (Pattern: mcp-papierkram, mcp-whatsapp, mcp-vf-hosted)

Beachte: MCP-Server selbst rufen meist KEIN Bedrock — sie sind Tools. Aber ihre Tool-Descriptions landen im System-Prompt jedes Callers der sie nutzt!

  • Tool-Description-Token-Footprint pro Tool gemessen (siehe templates/tool-description-audit.py).
  • Pro MCP gesamt ≤ 3000 Tokens an Tool-Descriptions (bei MCPs mit > 30 Tools: bis 5000 ok).
  • Selten genutzte Tools (< 1x pro Woche in CloudTrail/Logs) sind disabled: true markiert oder entfernt.
  • JSON-Schema ohne examples-Felder (sind Tokens, Modell braucht’s nicht).
  • Property-description nur wo nicht-trivial.
  • MCP-Eintrag in _index hat token-cost-tier (A/B/C) Spalte gefuellt.

Cross-Cutting (jeder Caller)

  • AWS Budget + Alarm existiert fuer den Account.
  • Bedrock Service-Quotas in den genutzten Regionen sind nicht auf Max-Default sondern auf Normal-Last + 20% Puffer.
  • Bedrock Model-Invocation-Logging ist aktiviert (CloudWatch oder S3-Sink).
  • CloudTrail-Trail loggt Management-Events (fuer AIP-Aenderungen Audit-Spur).
  • Run-Log Eintrag in intern/runs/<jahr>-<monat>.md beim ersten Live-Gang.

Wann den Audit fahren

  • Pflicht: vor Live-Gang eines neuen MCP, einer neuen Lambda-Routine, eines neuen ECS-Services.
  • Empfohlen: monatlich auf bestehende Caller (Cost-Drift detektieren).
  • Trigger-getrieben: bei Cost-Spike-Alarm aus Budget-Notification.

Verknuepfung zu anderen Skills

  • mcp-eigenbau SKILL muss diesen Audit als Final-Check vor cdk deploy referenzieren.
  • routine-anlegen SKILL muss die Typ-B-Checkliste als Brief-Bestandteil haben.
  • qa-staging SKILL kann optional Tool-Description-Token-Audit als Post-Deploy-Check einbauen.

Graphansicht