Tool Permissions für AI Agents (Least Privilege) + Code

Interaktiver Ablauf

Szenario:

Schritt 1/3: Execution

Action is proposed as structured data (tool + args).

Problem (aus der Praxis)

Der Agent ist „nur Text“. Bis du ihm Tools gibst.

Sobald ein Agent Tools callen kann, hast du ein Permissions-System gebaut. Ob du’s wolltest oder nicht.

Und hier ist die unbequeme Wahrheit: Prompts sind keine Permissions. „Please don’t do X“ ist kein Control Layer.

Warum das in Production bricht

1) „Give it access, we’ll constrain later“ endet im Incident

Wenn du denkst „wir geben erstmal Zugriff und bauen später Guardrails“: Glückwunsch, du beschreibst die Einleitung des Postmortems.

2) Tools sind Capabilities, nicht Funktionen

db.write ist nicht „eine Funktion“, es ist eine Capability: sie verändert State. Side Effects sind irreversibel oder teuer.

Design Tool Permissions als Capability Graph:

read vs write
scoped resources (tenant/project/user)
limits (rate/cost/steps)

3) Permissive Default ist der Weg zu Daten-Leaks

Default-Allow plus ein falscher Tool Call und du hast:

PII in Logs
writes in falsche Umgebung
cross-tenant access

Implementierungsbeispiel (echter Code)

Ein simple Permission Model:

capability-based allowlist
scope checks (tenant_id)
write tools optional behind approval

PythonJS

PYTHON

from dataclasses import dataclass


@dataclass(frozen=True)
class ToolPermission:
  name: str
  scopes: set[str]  # e.g. {"tenant:acme"}
  mode: str = "allow"  # allow | approve


class PolicyDenied(RuntimeError):
  pass


def check_permission(perms: list[ToolPermission], *, tool: str, scope: str) -> ToolPermission:
  for p in perms:
      if p.name == tool and scope in p.scopes:
          return p
  raise PolicyDenied(f"policy_denied:{tool}:{scope}")

JAVASCRIPT

export class PolicyDenied extends Error {}

export function checkPermission(perms, { tool, scope }) {
for (const p of perms) {
  if (p.name === tool && p.scopes.includes(scope)) return p;
}
throw new PolicyDenied("policy_denied:" + tool + ":" + scope);
}

Echter Incident (mit Zahlen)

Ein Agent hatte Zugriff auf einen „admin“ DB Tool Wrapper, weil es „bequemer“ war. Er sollte Support Tickets triagieren.

Ein Prompt Injection in einem Ticket hat ihn dazu gebracht, eine Query auszuführen, die mehr Daten zurückgab als nötig.

Impact:

kein Datenverlust nach außen (zum Glück)
aber PII im internen Log (das zählt trotzdem)
~6 Stunden Incident + Cleanup + Audit

Fix:

least privilege per tool (scoped creds)
output redaction im tool gateway
allowlist + approvals für writes

Abwägungen

Permission Modelle kosten Engineering-Zeit. Das ist günstiger als Incident-Zeit.
Mehr Scopes bedeutet mehr Policy Management.
Zu restriktiv kann Produkt-Value bremsen. Deshalb brauchst du gute Defaults + klare Escalation.

Wann du es NICHT nutzen solltest

Wenn du nur read-only Tools hast, brauchst du immer noch Scopes (tenant boundaries).
Wenn du Tools nicht scopen kannst (ein Tool kann „alles“): fix the tool, nicht die Policy.

Checkliste (Copy/Paste)

[ ] Capability-basierte Tool Namen (read vs write)
[ ] Default-deny allowlist
[ ] Scoped credentials pro tenant/user/project
[ ] Approval mode für irreversible writes
[ ] Output redaction (PII) + logging
[ ] Stop reasons: policy_denied

Sicheres Default-Config-Snippet (JSON/YAML)

YAML

tool_permissions:
  default: "deny"
  grants:
    - tool: "kb.read"
      scopes: ["tenant:acme"]
      mode: "allow"
    - tool: "ticket.close"
      scopes: ["tenant:acme"]
      mode: "approve"
logging:
  redact_outputs: true

FAQ (3–5)

Von Patterns genutzt

Erforderliche Governance

Warum reicht ein Prompt nicht als Permission?

Weil Prompts nicht enforce. Das Modell kann falsch liegen, halluzinieren oder injected werden.

Brauche ich Scopes wirklich?

Ja, sobald du multi-tenant bist oder unterschiedliche Umgebungen hast. Sonst leakst du früher oder später.

Wie kombiniere ich Permissions mit Budgets?

Permissions sagen ‚darf es?‘, Budgets sagen ‚wie lange/wie teuer?‘. Du brauchst beides.

Wo enforce ich das?

Im Tool Gateway. Nicht im UI, nicht im Prompt.

Q: Warum reicht ein Prompt nicht als Permission?
A: Weil Prompts nicht enforce. Das Modell kann falsch liegen, halluzinieren oder injected werden.

Q: Brauche ich Scopes wirklich?
A: Ja, sobald du multi-tenant bist oder unterschiedliche Umgebungen hast. Sonst leakst du früher oder später.

Q: Wie kombiniere ich Permissions mit Budgets?
A: Permissions sagen „darf es?“, Budgets sagen „wie lange/wie teuer?“. Du brauchst beides.

Q: Wo enforce ich das?
A: Im Tool Gateway. Nicht im UI, nicht im Prompt.