Kevin Welter.
ENDE

My AI employee

Find security flaws before they become expensive.

Falk has been running for me since August 31, 2026, and has completed an authorized engagement. Because every application needs its own scope and approval, I currently use him for targeted engagements rather than as a standard package.

Falk tests an application in stages: from the outside with no access at all (recon), then as an unauthenticated attacker from the outside (blackbox), and, where I approve it, with access or repo insight (greybox, whitebox). For every finding he delivers evidence, a CVSS severity rating and a concrete fix. He only tests systems that belong to me or for which written approval exists.

Join the communityRead first: Learning Claude
View community

Evidence

findings with reproducible proof

Prioritized

risk before busywork

Approval

no change without Kevin

Red teamer

A real workday

His first completed engagement ran against an application of my own, externally and with no prior access. What's here is the method, not the findings themselves: details about the target or the outcome stay in the internal engagement folder for good reason.

4

Testing stages in the model

2 of 4

Completed so far

max. 20 requests/min

Scan pace

Before a single request went to the target system, my written approval was in place. For Falk, that's a fixed gate, not a formality. The process followed five phases: first, reconnaissance, where he derives the technology in use strictly from publicly served files instead of guessing, then an attack surface model along the login and session flow, then manual tests for typical vulnerability classes like open redirects or information leaks in error messages, a tooling check of TLS configuration and an automated scan, and finally the assessment.

Every finding comes with a CVSS severity rating and a concrete, prioritized fix, not just a list of issues. The automated scan ran deliberately throttled: four parallel requests, capped at 20 per minute, no load or stress testing, no trying of credentials. Rate-limit etiquette toward the target system isn't an afterthought for Falk, it's a fixed part of the scope.

Falk for your business

Your application defines the scope. Falk does not.

Falk can assess different systems, but never under a blanket attack assignment. The target, allowed stages, access, rate limits and abort criteria are defined again for every engagement.

How I use him

Assess an application of my own in stages from the outside

Falk started with no access, modeled the attack surface, tested manually and with rate-limited tools, and documented every finding with a priority and fix.

Adapted to you

Your target system and your written scope

You define exactly which systems are included, which accounts may be used and where Falk must stop. Only then is the appropriate depth of testing selected.

What you change

  • Target system and allowed domains
  • Blackbox, greybox or whitebox
  • Rate limits and abort criteria
  • Report, review and approval

Other possible uses

  • Company website
  • Web API
  • Customer portal
  • Internal application

The process stays: Work only with written authorization, document scope and abort criteria first, avoid destructive testing and support every finding with evidence and a fix.

The tools he works with

Falk works with a staged toolkit, depending on which stage is approved for the engagement:

01

Inspect public signals

Passive recon tools that only read publicly served files and headers, no request with a side effect.

02

Trace login flows

Manual review of the login and session flow directly in the frontend code, no automated assumptions.

03

Scan for known weaknesses

A targeted, rate-limited automated scanner for TLS configuration and known vulnerability classes.

04

Log every step

A written scope and an engagement folder per job, logging every approval and every step.

What he can't do, where I approve

He only tests systems that belong to me or for which written approval exists. No test without scope approval in the job order.

Active scans, fuzzing or exploit attempts against a target system are gated, as is spending money, for example on commercial tools or cloud scan quotas.

Never: third-party systems without a written scope, destructive actions like outages or data deletion, exfiltration of real personal data, quoting found credentials in plain text.

Every engagement has fixed abort criteria: instability, unexpected data access, a third-party target, or rate-limit warnings stop the test immediately.

A findings report goes through a review pass by a separate reviewing role before I see it.

How to build Falk for your scope

Standard

Build him individually and with control

Entry point is Learning Claude, plus the articles on hiring and creating an AI employee. What's special about Falk: he thinks from an attacker's perspective instead of just ticking off checkpoints, he works in stages instead of firing tools at random, and every finding comes with a CVSS rating and a concrete fix, not just a warning.

  • Understand the build step by step
  • Adapt rules and examples to your own business

Premium

Individual scope instead of a standard package

Falk runs in my own business. A security test always needs its own scope and approval for the target system. That is why his process is tailored to the application instead of distributed as a generic template.

  • Use the documented build as your starting point
  • Define scope, access and approvals for your setup
Join the community

Frequently asked questions about Falk

How do I check if my website is secure?

A single check rarely covers it. A staged approach makes sense: first from the outside with no access, then as an unauthenticated attacker, and where it makes sense, with real access or repo insight. Free online checkers give a first impression, but they don't replace a targeted, manual check with evidence and a severity rating.

Can AI help with penetration testing?

Yes, in parts. AI can speed up recon, scan code for typical vulnerability patterns, and structure reports. For me, Falk works in stages and documents every step before acting. What he can't do: act on his own against third-party systems. Every test needs a written scope and my approval.

How do I test my own website for security flaws?

The first step is reconnaissance based strictly on publicly served files, with no assumptions. Next comes an attack surface model along the login and session flow, then manual tests for typical vulnerability classes and a rate-limited automated scan. At the end sits an assessment with a fix proposal for every finding, not just a list of errors.

What does a penetration test cost?

That depends heavily on the scope: the size of the application, which stages are approved, and whether it stays at an external blackbox check or also includes access or repo insight. For me this runs within my own business, so I can't honestly give a flat number without knowing the actual scope.

What's the difference between an automated scan and a real red team test?

An automated scan looks for known patterns and reports hits without understanding the context. A red team test like Falk's combines that with manual review, an attack surface model, and a severity rating with a fix proposal. The scan is one tool inside it, not the whole test.

Finding security flaws before an attacker does

There's no template for Falk's exact setup, but the learning path he grew out of is in the community.

Join the community

Read on

Also:Langdock vs Claude: What I Use and Why·Securing Your Own Server: Linux and Windows·What Does a Security Audit Cost?·How to Check an SSL Certificate·Website Security Audit: Steps and Checklist·Check Your Website Security Online·Learn Claude: The Path in Five Stages·Hiring an AI Employee: The Process·Creating an AI Employee: How to Start·Claude Privacy and GDPR: What Applies·Hire Your First AI Employee in One Hour·Building an AI Team: My Org Chart