# What Building an Autonomous Registration Module Taught Me > 2026-06-06 · notes from building the autonomous security agent ![[Pasted image 20260606161921.png]] After spending the last week building the registration and authentication layer of my autonomous IDOR agent, I no longer believe that's true. The hardest part is getting the agent to become a legitimate user. Before an agent can test authorization boundaries, discover IDORs, validate privilege escalation paths, or analyze object ownership, it first needs an account. And it turns out that account creation is far more chaotic than I expected. ## My Original Assumption My first design was embarrassingly simple. The workflow looked something like this: 1. Crawl the application. 2. Extract JavaScript routes. 3. Search for keywords: - register - signup - login - auth - join 4. Navigate to the discovered route. 5. Create an account. 6. Continue with the security testing. Conceptually it felt clean. In reality, it broke almost immediately. ## Testing Against Real Targets Changed Everything I validated the module against 30 real-world applications. Not toy examples. Real SaaS platforms, developer tools, healthcare systems, consumer applications, and cloud services. The first batch produced an uncomfortable result: - 83% of targets were classified as `unknown` - CAPTCHA detection failed on known targets - Several registration forms were never discovered - OAuth-only flows were incorrectly categorized - Multiple applications exposed registration only after browser interaction The code looked correct. The assumptions were wrong. ## Lesson 1: Registration URLs Are Meaningless I started by assuming routes would reveal intent. That assumption failed immediately. Some platforms use: - /signup - /register - /join - /create-account - OAuth redirects - Modal-based registration - Client-side generated routes Others don't expose registration routes at all until JavaScript executes. One of the first improvements was implementing multi-path probing instead of relying on a single registration endpoint. The result: Unknown classifications dropped immediately. But the bigger lesson was architectural: **URLs are implementation details. Behavior is what matters.** ## Lesson 2: Static Analysis Has a Hard Ceiling The second major discovery came from comparing static HTML parsing against browser-assisted analysis. Initially the agent only inspected server-rendered content. The logic seemed reasonable: "If the form exists, I should be able to see it." Modern applications proved otherwise. React. Vue. Next.js. Angular. Many applications don't render authentication components until hydration completes. When I switched to browser-assisted analysis the results changed dramatically. Static Mode: - Correct classifications: 7/30 Browser Mode: - Correct classifications: 7/10 on the sampled subset Applications previously classified as unknown suddenly exposed: - Email/password registration - OAuth providers - CAPTCHA widgets - Multi-step onboarding flows The improvement wasn't incremental. It was transformational. The conclusion became obvious: Static analysis is useful for screening. Browser analysis is required for decision-making. ## Lesson 3: Authentication Discovery Deserves Its Own Layer Originally authentication was simply one step inside registration. The testing process exposed why this was wrong. Before attempting registration, the agent needs to answer several questions: - Is registration available? - Is this email/password? - Is this magic-link authentication? - Is OAuth mandatory? - Is enterprise SSO enforced? - Is browser interaction required? - Is there a CAPTCHA? Those questions are independent of account creation itself. That realization led me to separate authentication discovery into its own LangGraph node. The node's responsibility is not registering users. Its responsibility is deciding how registration should be attempted. That distinction simplified the entire system. ## Lesson 4: CAPTCHA Detection Is Fundamentally Incomplete This was probably the most surprising discovery. I initially believed CAPTCHA detection was a classification problem. Detect widget. Identify type. Choose solver. Simple. Reality was messier. During testing I encountered: - reCAPTCHA v2 - Cloudflare Turnstile - hCaptcha - Invisible challenges - Submit-triggered challenges The last category completely changed my thinking. Some CAPTCHAs do not exist during page load. They only appear after form submission. This means pre-flight analysis can never achieve perfect detection. The information literally does not exist yet. That forced a redesign. Instead of trying to predict everything up front: Authentication Strategist → Initial Plan Executor → Adaptive Discovery The strategist proposes. The executor adapts. This mirrors how human testers actually behave. ## Lesson 5: The Agent Must Be Allowed To Be Wrong The most important architectural lesson wasn't technical. It was philosophical. My first instinct was to build a system that always made the correct decision. Testing quickly showed that was unrealistic. No matter how many heuristics I added: - New frameworks appeared - New authentication flows appeared - New CAPTCHA implementations appeared - New onboarding patterns appeared The solution was not more rules. The solution was feedback. The agent must be able to: - Make a decision - Observe the result - Detect failure - Adapt Reliability comes from correction loops. Not prediction. ## Why LangGraph Became Important This experience completely changed how I think about agent architecture. A registration engine sounds like a single problem. It isn't. It's at least five independent problems: Authentication Discovery ↓ Strategy Selection ↓ CAPTCHA Handling ↓ Registration Execution ↓ Verification & Recovery Once each responsibility became its own node: - Testing became easier - Debugging became easier - Observability improved - Components became replaceable - Failures became isolated Instead of debugging one giant workflow, I could validate each decision independently. ## The Metrics That Changed My Mind Some of the most valuable insights came from measuring the system. Validation batch: - 30 real-world targets - Multiple authentication mechanisms - Browser-assisted and static analysis modes - OAuth, email/password, magic-link and hybrid flows Findings: - Static analysis classified only ~23% correctly - Browser-assisted analysis achieved ~70% classification on tested targets - Multi-path probing significantly reduced unknown states - CAPTCHA detection improved by ~50% with browser rendering - Most failures came from assumptions, not implementation bugs The data forced architectural changes that I would never have made from theory alone. ## Final Takeaway I started this project believing vulnerability discovery would be the difficult part. Instead, I spent most of my time teaching the agent how to become a user. And honestly, that makes sense. Every security test begins with authentication. Every authorization test begins with identity. Every IDOR begins with ownership. If your agent can't reliably navigate registration and authentication workflows, it never reaches the interesting security problems. The biggest lesson from this week is simple: Registration is not a feature. It's an entire domain. And the moment you test against real applications, you discover how much complexity has been hiding behind a single "Sign Up" button. --- Next article: **What 30 Real Applications Taught Me About CAPTCHAs** Including: - reCAPTCHA v2 - Cloudflare Turnstile - hCaptcha - Invisible challenges - Submit-triggered CAPTCHAs - Why CAPTCHA detection can never be fully deterministic More technical notes and research: [https://r0b1ng00d.com](https://r0b1ng00d.com/)