Alle Assessment-Infos auf einen Blick: One-Pager (PDF) herunterladen.
Den Einsatz von AI Coding Agents absichern
Die meisten Engineering-Organisationen liefern bereits heute Code aus, der mit Unterstützung von AI Coding Agents entstanden ist. GitHub Copilot, Cursor, Claude Code, Codex, OpenCode, Windsurf, Devin, Aider und ein langer Schwanz an MCP-basierten Erweiterungen sind im produktiven Einsatz, oft bevor Security oder Legal das formal geprüft haben. Das Muster ist immer dasselbe: Entwickler:innen sind begeistert, die Produktivitätszahlen ziehen an, und das Security-Team hat keine belastbare Antwort auf die Frage, wie das eigentlich gesteuert wird.
Dieses Assessment liefert die Antwort in zwei Sessions. Wir arbeiten gemeinsam einen strukturierten Workshop mit 78 Fragen über neun Domänen durch: Adoption, Governance, Identity & Secrets, MCP & Tool Connectivity, Code- und Datenexposition, Generation Safety, Supply Chain, Execution Sandboxing und Monitoring. Aus den Antworten entstehen eine priorisierte Risikoübersicht und eine zweistufige Remediation-Roadmap, die die nächsten neun Monate abdeckt.
Die Struktur ist schlicht: ein Ersttermin zur Erhebung, ein zweiter Termin zu den Ergebnissen und der Roadmap.
Vor dem Assessment führen wir ein kurzes Scoping-Gespräch. Es klärt, welche Agenten und Teams in Scope sind, welche Themen besondere Tiefe bekommen sollen und wer in welcher Session dabei sein sollte.
Wenn Ihr Anliegen die AI Agents sind, die Sie selbst bauen und Ihren Kund:innen anbieten (Chatbots, autonome Orchestrierungen, Multi-Agent-Systeme), ist Agentic AI Security der passende Service. Dort geht es um Angriffe gegen Ihr AI-Produkt. Hier geht es um Angriffe gegen Ihre Software-Supply-Chain über die AI-Werkzeuge, mit denen Ihre Engineers alles andere bauen.
Warum bestehende Controls das nicht abdecken
Coding Agents wirken auf den ersten Blick nicht wie eine neue Bedrohungsfläche. Der Entwickler öffnet weiterhin eine IDE, schreibt Code, öffnet einen Pull Request. SAST läuft, Dependency-Scanner laufen, Code Review findet statt. Auf dem Papier hat sich nichts geändert.
Was sich geändert hat: wer den Code schreibt, welcher Code Ihr Netzwerk verlässt und welche Privilegien dieser Schreibvorgang besitzt.
Der Agent läuft als der Entwickler. Ein Coding Agent mit Shell-, File-Write- und Network-Tools erbt die effektiven Rechte der Person, die ihn startet. Auf einer Workstation mit lokalem Admin oder gespeicherten Cloud-Credentials ist ein prompt-injizierter Agent ein berechtigter Insider. Sandboxing der Agent-Ausführung und sauber begrenzte Tool-Berechtigungen werden im agentengestützten Workflow wichtiger als zuvor.
Der Vendor sieht mehr, als die meisten annehmen. Inline-Completions schicken kleine Fenster. Chat mit Projektkontext schickt geöffnete Dateien. Cursor Background Agents und vergleichbare Cloud-Worker klonen ganze Repositories in die Vendor-Infrastruktur. Die wenigsten Organisationen haben bewertet, welche dieser Pfade ihre Teams tatsächlich nutzen, welche Vendor den entstehenden Code halten und welche vertraglichen Datenverarbeitungszusagen es dazu gibt.
MCP ist die am schnellsten wachsende Integrationsfläche im Dev-Stack und sicherheitsseitig die am wenigsten reife. MCP-Server bekommen Credentials, halten privilegierten Tool-Zugriff und kommen als Pakete aus npm, PyPI, GitHub oder von Vendor-Sites. Sie werden mit derselben Beiläufigkeit eingebunden wie andere Dev-Dependencies und bekommen Shell-, Datenbank- und Cloud-SDK-Zugriff. Tool-Beschreibungen werden Teil des Agentenkontexts, was eine bösartige Beschreibung zu einer persistenten Prompt-Injection macht.
Shadow Adoption ist der Normalfall, nicht die Ausnahme. Persönliche Vendor-Accounts umgehen SSO, DPAs und Audit. Engineers fügen Produktions-Stacktraces in Chat-Boxen ein. Slopsquatted Dependencies, die ein überselbstsicherer Agent vorschlägt, landen in Lockfiles. Nichts davon taucht in einem klassischen Application-Security-Review auf.
Dieses Assessment ist genau für diese Lücke gebaut. Es ist kein Pentest, kein Code Review und kein Training. Es ist ein strukturierter Workshop und ein belastbarer Report, mit dem Sie mit Evidenz sagen können, wo Sie stehen und was Sie als Nächstes tun.
Bewertungsabdeckung: neun Domänen
Workshop und Report sind in dieselben neun Domänen organisiert. Jede bekommt im Bericht ein eigenes Severity-Urteil, mit Findings, die auf anerkannte Standards zurückgemappt werden.
Inventar und Adoption
Was tatsächlich im Einsatz ist, von wem und wo es läuft.
Wir besprechen gemeinsam, welche Agenten in Ihrer Organisation im Einsatz sind — sanktioniert, geduldet oder als Shadow-Use bekannt — und wie sich die Nutzung über Teams, Geografien und Seniorität verteilt. Wir gehen Deployment-Modes (IDE-Plugin, CLI, Web, Code-Review-Bot, autonomer CI/CD-Agent) und, getrennt davon, Runtime-Locations (lokaler IDE-Prozess, lokales CLI, unternehmensgehosteter Runner, Vendor-Cloud-Background-Agent, browserbasierter Cloud-Workspace) durch. Die Unterscheidung der Runtime-Location trägt hier den größten Teil der Risikoanalyse: Ein lokales Plugin lässt Code auf der Dev-Maschine, ein Vendor-Cloud-Background-Agent klont das Repository in die Vendor-Infrastruktur. Dieser eine Unterschied formt das nachgelagerte Risikobild.
Außerdem nehmen wir auf, wie breit die Adoption ist, wie viel Sichtbarkeit über Shadow-Nutzung besteht (wissen Sie eigentlich, wer was benutzt), wie der Anteil unternehmenseigener und persönlicher Accounts aussieht, welche Repository-Scope-Regeln greifen und in welchen Umgebungen Agenten laufen (Laptop, Devcontainer, Codespaces/Gitpod/Coder, CI/CD, Produktions-Debugging, Kundenumgebungen).
Governance und Policy
Das schriftliche Grundgerüst rund um AI-Coding-Adoption.
Wir besprechen, ob es eine formale AI-Coding-Policy gibt, ob neue Agenten und MCP-Server ein echtes Approval Gate durchlaufen oder Self-Service sind, wie Risiko klassifiziert wird und welche Vendor Due Diligence bei den Agent-Vendors gelaufen ist, die Ihren Quellcode in die Hand bekommen. Training und Awareness gehören in diese Domäne: Umgang mit Secrets in Prompts, Prompt Injection in eingefügtem Material, IP- und Lizenzrisiken, Social Engineering von Agenten durch vergiftete Dokumente, Slopsquatting-Bewusstsein und Awareness für destruktive Aktionen.
In vielen Engagements ist diese Domäne „ad hoc", während die Pipeline-seitigen Controls bereits ausgereift sind. Diese Asymmetrie fällt später auf, wenn jemand nach Evidenz fragt.
Identity, Authentifizierung und Secrets
Wer der Agent ist, welche Credentials er hält und was Ihre Secrets davon abhält, die Workstation zu verlassen.
Wir besprechen das vorherrschende Identitätsmodell (Corporate SSO vs. persönliche Vendor-Accounts vs. geteilte Service-Accounts), SSO- und SCIM-Durchsetzung über alle Agent-Vendors hinweg und Secret-Redaction-Controls auf Agent-Traffic. Wir nehmen auf, wo entwicklerseitige Secrets tatsächlich liegen (zentraler Secret Manager, OS-Keychain, .env-Dateien, IDE-Config, Shell-History, Source Code), denn ein Coding Agent mit File- oder Shell-Tools liest alles, was die Entwicklerin lesen kann.
Token-Scope und Lifetime bekommen explizite Aufmerksamkeit. Viele Umgebungen stehen per Default auf Full Repo Write mit gemischten oder unbefristeten Lifetimes. Das ist ein einzeiliges Finding mit messbarer Remediation. Wir besprechen außerdem das Risiko von Secrets in Chat-Historien, das Credential-Provisioning von MCP-Servern und Session-Isolation über Nutzer, Repos und Projekte hinweg.
MCP und Tool Connectivity
Die Integrationsschicht, die schneller wächst als ihre Sicherheits-Controls.
Wir nehmen die MCP-Server in aktiver Nutzung auf (GitHub, Slack, Atlassian, interne Forks usw.), gehen Source Vetting vor Adoption, Hosting-Modelle (lokal auf der Dev-Maschine, im Devcontainer, zentral als interner Service, Vendor SaaS) und Network-Egress-Posture durch. Tool-Description-Audits und Rug-Pull-Detection gehören in diese Domäne: Ein heute harmloser MCP-Server kann morgen durch ein Upstream-Update bösartig werden.
Die Capability-Fläche ist die andere Hälfte. Wir gehen durch, welche Tool-Kategorien Ihre Agenten aufrufen können (Shell-Execution, File Write inner- oder außerhalb des Workspaces, Network Requests, Browser-Automation, Datenbankzugriff, Cloud-SDK- und IaC-Tools, E-Mail-/Messaging-Versand, Code-Execution-Sandboxes) und besprechen die Defaults für Tool-Approval. Der Unterschied zwischen „jede Aktion verlangt Bestätigung" und „Full Auto" formt Ihren Blast Radius stärker als jeder andere Einzelparameter.
Drittanbieter-Marktplätze (Cursor-Extensions, IDE-Plugin-Stores, MCP-Verzeichnisse) bekommen einen eigenen Punkt, weil sie eine Discovery-Schicht mit begrenzten Sicherheitsgarantien sind.
Den Bedrohungsblick, der dieser Domäne zugrunde liegt, beschreibe ich im Blogpost zu MCP mit einer Defense-First-Architektur absichern.
Code-Kontext und Datenexposition
Welcher Code Ihr Netzwerk verlässt, wohin er geht und was der Vendor damit tun darf.
Verschiedene Produkte senden unterschiedlich viel Code. Inline-Completions schicken kleine Fenster. Chat mit Projektkontext kann ganze geöffnete Dateien senden. Background Agents klonen das Repository in die Vendor-Infrastruktur. Wir besprechen, welche dieser Pfade Ihre Teams tatsächlich nutzen und ob sensible Repositories (PCI, PHI, Kunden-Kryptomaterial, geschäftskritische Logik) gesondert behandelt werden oder mit allem anderen in einen Topf wandern.
Wir gehen gemeinsam durch, welche vertraglichen Zusagen des Vendors zur Datenverarbeitung vorliegen oder bekannt sind (Training-Opt-out, Zero-Retention-Modes, Region Pinning, DPA, BYOK), wie weit der Telemetrie-Umfang für Prompts reicht, ob selbst gehostete Alternativen für sensible Workloads verfügbar sind, welche Controls für Agent-Langzeit-Memory greifen und welche IP-Klassifizierung Repo-Level-Regeln treibt. Das Risiko, dass Kundendaten oder PII in Agent-Prompts landen, ist ein häufiger Schmerzpunkt und bekommt eine eigene Zeile.
Generation Safety und Quality Gates
Was vom Agenten zurückkommt, und was die schlechten Teile abfängt, bevor sie ausgeliefert werden.
Wir besprechen, ob Human Review von AI-generiertem Code verpflichtend, optional oder ausgelassen ist und ob AI-authored Code attribuiert wird (Tag, Comment oder Commit Trailer). Anschließend gehen wir den Security-Scanning-Stack durch, der tatsächlich in der Pipeline hängt (SAST, Secret Scanning, SCA, IaC, Container, License Compliance), denn AI-generierter Code konzentriert bestimmte Bug-Klassen: schwache Krypto, breite CORS, eval/exec, SQL-String-Konkatenation, unsichere Deserialisierung, deaktivierte TLS-Verifikation.
Prompt-Injection-Defenses für Source Inputs (Issues, PR-Comments, Code-Comments, von Agenten konsumierte Retrieval-Inhalte) gehören in diese Domäne. Ebenso Controls gegen destruktive Aktionen (Pre-Execution-Diff/Preview, Confirmation Prompts, Allowlists, Sandbox-Execution, Snapshots), Test-Coverage-Anforderungen für AI-generierten Code, Commit-Signing und Attribution für Agent-Commits sowie Lizenzkontaminations-Checks.
Supply Chain und Dependency Risk
Die Pakete, Binaries und Rule Files, die mit AI-gestützter Entwicklung mitfahren.
Slopsquatting (von AI halluzinierte oder kürzlich registrierte Typosquats) ist hier das operationell relevanteste Risiko. Wir gehen die Controls durch, die zählen: interne Registry oder Proxy mit Allowlist, Lockfile-Enforcement, Pre-Install-Scanning, Cooling Periods für frisch veröffentlichte Pakete und Human Review für AI-vorgeschlagene Dependencies.
Über Pakete hinaus ist auch der Agent selbst ein Binary, das mit Entwicklerprivilegien läuft. Wir besprechen, wie Agent-Binaries auf Maschinen gelangen (vendor-signierter Installer, Corporate App Store, interner Mirror, Public Marketplace, direkter Web-Download) und wie MCP-Server selbst hereingeholt werden (Signing, Version Pinning, interner Fork oder Mirror, Update-Review). Drittanbieter-Rule-Packs, System Prompts und Personas (Cursor-Rules, CLAUDE.md-Fragmente, Copilot Custom Instructions, Agent-Persona-Bibliotheken) bekommen einen eigenen Punkt, weil sie unsignierte Textfragmente sind, die Agent-Verhalten formen und verdeckte Instruktionen tragen können.
SBOM-Abdeckung für AI-eingeführte Dependencies und die vertragliche Position dazu, ob Ihr Code Vendor-Modelle trainiert, schließen diese Domäne ab.
Execution Environment und Sandboxing
Wo agenten-initiierte Kommandos tatsächlich ausgeführt werden, und was sie davon abhält, weiter zu kommen als gewünscht.
Wir besprechen, wo Shell-Kommandos und Code, die der Agent ausführt, tatsächlich laufen (Laptop-Host-OS, lokaler Devcontainer, Remote-Dev-Environment, vendor-gehosteter Runner, CI/CD-Runner, Produktion read-only, Produktion mit Write), wie stark die Shell-Sandbox ausgeprägt ist (microVM, Container mit reduzierten Rechten, Container mit Default-Rechten, Process-only, keine) und welche Network-Egress-Controls in der Dev-Umgebung greifen.
Dev-Maschinen-Härtung (EDR, Full-Disk-Encryption, MDM, Host-Firewall, lokaler Least-Privilege-User, Application Allowlisting) wird explizit abgedeckt, weil der Agent den Containment-Stand des Hosts erbt. Agent-Zugriff auf Produktion, der Einsatz von Coding Agents in der CI/CD-Pipeline (PR-Review-Bots, autonome Bugfixes, Testgenerierung, Security-Finding-Triage) und ob Agenten Branch Protections oder CODEOWNERS umgehen können, runden diese Domäne ab.
Monitoring, Audit und Incident Response
Die Sichtbarkeit, von der alles andere abhängt.
Wir besprechen, was zentral geloggt wird (Prompts, Completions, Tool- und MCP-Aufrufe mit Argumenten, Network-Traffic von MCP-Servern, Commits und PRs von Agenten, Authentication- und Session-Events), Retention-Policy, SIEM-Integration und ob Anomaly Detection auf Agent-Verhalten getunt ist (ungewöhnliche Tool-Sequenzen, Exfiltrations-Muster, Spitzen destruktiver Aktionen, Off-Hours-Aktivität, Cross-Repo-Aktivität aus einer Session).
Wir gehen außerdem darauf ein, ob für die vier häufigsten agentenspezifischen Szenarien (vergifteter MCP-Server, geleaktes Agent-Token, durch Prompt Injection ausgelöste destruktive Aktion, Vendor-Datenexposition) ein IR Playbook existiert und ob Credential Revocation in einer Tabletop-Übung Ende-zu-Ende gemessen wurde. Forensische Fähigkeiten (Full Session Replay, Transcript-Export, Tool-Call-Audit-Log, Network-Capture) bekommen einen eigenen Punkt, weil sich an dieser Stelle entscheidet, ob aus einem Incident ein Postmortem wird oder eine Vermutung.
Die Kategorie schließt mit einem Selbst-Assessment der Reifegrad-Bewertung von 0 bis 10. Sie verankert den Report und gibt Ihnen eine messbare Baseline zur Verbesserung.
Was Sie erhalten
Am Ende des Engagements erhalten Sie drei Artefakte.
Eine Risikoübersicht. Eine priorisierte Sicht auf die Risiken über die neun Domänen hinweg, basierend auf den tatsächlichen Workshop-Antworten Ihrer Organisation statt einer generischen Checkliste. Jeder Punkt benennt, was es ist, warum es in Ihrer Umgebung relevant ist und welche Severity sich aus Ihrem Nutzungsprofil ergibt.
Eine zweistufige Remediation-Roadmap. Wave 1 für die nächsten 0–3 Monate deckt die Grundlagen ab. Wave 2 für 3–9 Monate deckt die Verstärkungsarbeit ab. Jeder Roadmap-Punkt verweist zurück auf das konkrete Risiko, das er adressiert.
Einen Residual-Risk-Ausblick. Wo Sie nach jeder Wave stehen, welches Risiko verbleibt und welche Kategorien strukturell sind statt behebbar. Geeignet für Vorstands- und Leadership-Kommunikation.
Der Report ist für zwei Lesergruppen geschrieben: für Security-Leadership oder Head-of-Engineering, die die Executive Summary liest, und für Platform oder Detection Engineering, die Risikoübersicht und Roadmap Zeile für Zeile liest.
Engagement-Ablauf
Scoping-Gespräch
Ein kurzes Gespräch, um den Scope zu klären, bevor irgendeine Vorbereitung beginnt.
Assessment-Workshop (Session 1)
Wir arbeiten die 78 Fragen live gemeinsam durch, im vereinbarten Format.
Report-Produktion
Remote, zeitnah nach dem Workshop.
Risiko- und Roadmap-Session (Session 2)
Wir gehen den Report gemeinsam durch.
Follow-up-Check-in (optional)
Ein kurzer Termin, sobald Sie eine Weile mit dem Report gearbeitet haben.
Sowohl der kundenseitige als auch der expertenseitige Zeitaufwand liegt bei jeweils zwischen ein und zwei Tagen, verteilt auf die beiden Sessions, plus dem optionalen Follow-up. Die Gesamtdauer (Kalenderzeit) beträgt typischerweise ein bis zwei Wochen, weil die Aufbereitung zwischen den Sessions asynchron stattfindet.
Ist dieses Assessment für Sie passend?
Das Engagement passt, wenn AI Coding Agents bereits produktiv in Ihrer Engineering-Organisation eingesetzt werden, wenn Leadership oder Kund:innen fragen, wie AI-gestützte Entwicklung gesteuert wird, oder wenn Sie die Lücke zwischen starker MCP-Adoption und fehlendem Vetting, Logging und Incident Response zu spüren beginnen.
Es ist außerdem nützlich als Baseline vor größeren architektonischen Entscheidungen: Wahl zwischen Vendor-Cloud-Background-Agents und selbst gehosteten Alternativen, Designentscheidungen für die nächste Iteration Ihrer Dev-Environment-Härtung, die Entscheidung, welche Repositories nie einen Coding Agent sehen sollen, oder der Aufbau der Policy, die im nächsten Quartal in Ihrem Acceptable-Use-Dokument landet.
Wenn Sie früher unterwegs sind (Adoption wird noch erkundet, ein Pilot läuft in einem Team, das Security-Team ist neu in dem Thema), ist eine 3-stündige Custom Focus Session zu den wirksamsten Controls die richtige Wahl. Das Intro lässt sich später, wenn die Zeit reif ist, in das vollständige Assessment überführen.
Hintergründe zu den Bedrohungsmustern, auf die dieses Assessment aufsetzt, finden sich in meiner Forschung und Blog-Serie sowie im Engagement Agentic AI Security — die richtige Wahl, wenn es um die AI-Systeme geht, mit denen Ihre Kund:innen interagieren, statt um die AI-Werkzeuge, die Ihre Engineers nutzen.
Bereit, den Einsatz von AI Coding Agents in Ihrer Organisation zu bewerten? Lassen Sie uns sprechen — über das Scoping des Zwei-Sessions-Pakets für Ihr Team.