Inf1n1tydes0ul Oneinfinity Docs

One&Infinity — Skill Boundaries

Defines what this system does well, what it does not, and where accuracy limits apply.

What the System Is Good At

Confirmed Working (Validated in Codebase)

Probabilistic / Best-Effort

What the System Is NOT Good At

• Blind SSRF without out-of-band callback: The validator checks for metadata reflection; blind SSRF requires external collaborators (Burp Collaborator, interactsh).
• Stored XSS validation: Only reflected XSS is automated; stored XSS requires a separate rendering step.
• DOM XSS validation: The browser_analysis pipeline phase uses Playwright for DOM XSS sink analysis, but validation of confirmed DOM XSS still requires manual review — the engine detects potential sinks, not confirmed exploitability.
• Authenticated endpoint testing: The scanner does not handle session management, CSRF tokens, or multi-step login flows automatically.
• Rate limit bypass: No automatic detection of WAF rate limiting on specific endpoints.
• Zero-day discovery without prior pattern: The zero-day engine uses anomaly heuristics (timing, status changes, reflection), not novel vulnerability classes.
• Network-level vulnerabilities: No port scanning correlation with findings; nmap integration generates scripts but doesn't auto-parse results into the graph.
• Mobile dynamic analysis without device: Frida/Objection require a rooted/jailbroken device or emulator connected at runtime.

Accuracy Boundaries

Secret Detection

• False positive rate: ~15% for generic_api_key type (keyword-only match). High-specificity types (AWS, GitHub PAT, Stripe) have ~5% FP rate.
• False negative rate: Secrets in binary files, encrypted archives, or obfuscated code are not detected.
• Entropy threshold: 3.8 bits/char for short strings, 4.5 for strings >64 chars.

Vulnerability Validation

• XSS confirmation rate: ~90% of reflected XSS found by dalfox are confirmed by the canary method.
• SQLi error-based confirmation: ~85% for MySQL/PostgreSQL; lower for MSSQL (different error patterns).
• Timing-based SQLi: ~70% true positive rate due to network jitter.
• Confidence classifier thresholds: confirmed requires ≥ 0.70 confidence + evidence/payload present; below 0.35 is automatically classified false_positive and excluded from reports. AI-theory findings are always capped at unverified (max 0.40 confidence) regardless of source confidence.
• Tool-source bonus: Findings from tool-confirmed sources receive +0.15 confidence before threshold evaluation.

Exploit Chains

• Only 6 predefined patterns. Multi-hop chains beyond these patterns are not automatically detected.
• Chain detection fires when ANY finding with the trigger vuln type exists (medium+ severity) — it does NOT verify that the specific finding is actually exploitable.
• Chain findings generated by ExploitChainEngine are tagged source_type=simulated and classified as simulated by FindingClassifier — they are excluded from submitted reports unless independently confirmed by ExploitChainExecutor HTTP execution.

Supported Use Cases

1. Bug bounty reconnaissance and hunting — primary design target
2. Authorized penetration testing — requires scope.yaml with authorized: true
3. GitHub secret intelligence — OSINT on public repos for target domains
4. CI/CD integration — results via JSON export, gen_report.py for HTML output
5. Security research — research mode with theory generation + anomaly detection

Unsupported Use Cases

• Unauthorized scanning of systems without written authorization
• Production credential validation beyond read-only API checks
• Social engineering or phishing infrastructure
• DoS or denial-of-service testing