Frequently asked questions

NIMIS is an AI-powered penetration testing platform for web applications. It applies the same methodology as a manual penetration test, thinking and probing the way an experienced tester would, but delivers it in a fraction of the time.

Every finding is backed by reproducible evidence rather than a theoretical flag. We deliver proof, not promises.

Conventional tools follow fixed scripts and signature rules, an approach that only holds up for a narrow, predictable set of cases and falls apart on anything it wasn’t explicitly built to look for. NIMIS is different: it reasons about your application and makes judgement calls in the moment, closing the gap between what an automated scanner can find and what a skilled human tester would pursue.

Behind it sits a purpose-built reasoning engine: an orchestration of custom and open-weight models refined specifically for penetration testing. Our proprietary algorithms let NIMIS make decisions a vulnerability scanner never could, but an expert penetration tester would.

No. A traditional scanner matches responses against signatures and tends to produce long lists of unverified “potential” issues. NIMIS explores like a person and, wherever possible, proves a vulnerability by actually triggering its effect: for example causing a controlled script to execute, receiving an out-of-band callback from your server, or demonstrating access to data that should be off-limits.

That distinction, verified exploitation over pattern-matching, is the core of how we keep false positives low.

They solve different parts of the same problem, and they work well together. A manual pentest is a valuable exercise, but its depth and consistency depend heavily on the individual operator and the time they are given. NIMIS applies a rigorous, repeatable methodology every time, with the breadth, speed and consistency to test thoroughly in hours and again on every change.

Many teams use NIMIS for continuous coverage and regression testing and bring in human specialists for periodic deep-dive work. We see NIMIS as a complement to human expertise, not a replacement for it.

NIMIS covers a broad range of web and API vulnerability classes, aligned to the OWASP Top 10:

• Injection: SQL injection (error, boolean, union and time-based), NoSQL injection, command and template injection (RCE), and XXE.
• Cross-Site Scripting (XSS): reflected, stored and DOM-based, across URL, POST body, headers, cookies, path and window.name.
• Broken Access Control: IDOR, cross-account data access, missing authorisation and mass assignment.
• Authentication & session flaws: session fixation and invalidation, weak session tokens, JWT misconfiguration, and missing login rate-limiting.
• Server-Side Request Forgery (SSRF) and Open Redirect.
• Security misconfiguration: missing or weak security headers, CORS, TLS/HTTPS weaknesses, mixed content, DNS security, and directory/file exposure.
• Sensitive data exposure: leaked keys, tokens and credentials, and verbose error disclosure.
• Vulnerable & outdated components: outdated libraries and server software, cross-checked against a public vulnerability database (OSV) for known CVEs.

Yes. NIMIS’s coverage maps across all ten OWASP Top 10 categories, plus additional classes such as the full range of XSS variants, open redirect and DNS security.

• A01 Broken Access Control: IDOR, cross-account access, CSRF, mass assignment.
• A02 Cryptographic Failures: TLS/HTTPS and transport/cookie security.
• A03 Injection: SQLi, NoSQLi, RCE/template injection, XXE, XSS, path traversal.
• A04 Insecure Design: CSRF, session handling, security-header hardening.
• A05 Security Misconfiguration: headers, CORS, directory/file exposure, mixed content.
• A06 Vulnerable & Outdated Components: library/server version detection with CVE lookup.
• A07 Identification & Authentication Failures: session management, JWT, login brute-force.
• A08 Software & Data Integrity Failures: outdated/at-risk components.
• A09 Security Logging & Monitoring: information and verbose-error disclosure.
• A10 Server-Side Request Forgery: SSRF.

NIMIS confirms a vulnerability by observing its actual effect rather than guessing from a pattern:

• Where it makes sense to do so, NIMIS safely exploits a weakness to prove it is real, demonstrating genuine impact rather than theoretical risk.
• It relies on observable evidence (real side effects, out-of-band callbacks, and measurable, reproducible differences in behaviour) rather than a single suspicious response.
• It stops at proof. NIMIS does not exfiltrate data, move laterally, establish persistent access, run denial-of-service or brute-force attacks, or perform social engineering. Testing always stays within the agreed scope.

Yes. You can provide one or more test accounts, and NIMIS will authenticate and explore the areas of the application behind the login, maintaining the session as it goes. See “How do I test areas behind authentication?” below.

No, and that’s a real difference. Many scanners can only reach authenticated areas if you hand them a valid token, and some need you to wire up the exact login form and steps by hand. NIMIS works it out for itself: give it a test account and it figures out how to log in, where to go, and what’s worth testing, the way a human tester would, without the manual setup.

You define the scope when you register an application. Testing is confined to the application’s own domain or subdomain, plus any additional API domains you explicitly add and verify. Within that, allowed and denied path rules let you fine-tune coverage.

Scope is enforced at several independent layers, so a URL outside your defined scope is never exercised.

Yes, that is what denied paths are for. Add any path fragment (for example /admin, /billing, or delete) to the denied list and NIMIS will not inspect or test any path containing it.

If you want the opposite, to concentrate testing on specific areas, you can add allowed paths, which take precedence. Denied paths are the recommended way to keep genuinely sensitive or fragile functionality out of scope.

You can add additional API domains (for example api.example.com or api.example.com/v1) to bring them into scope. Each additional domain must pass the same ownership verification as your main application before any testing occurs, so you can only ever extend testing to infrastructure you control.

When you register an application you can supply test accounts: a username and password, plus a priority if you provide more than one. NIMIS uses these to authenticate and explore functionality behind the login.

We strongly recommend dedicated test accounts on a non-production environment rather than real user credentials.

No. You set a maximum request rate (from 10 up to 100 requests per second) when you configure the application. On top of that ceiling, NIMIS’s models continuously watch how your application is responding and automatically back off (reducing the rate) if they see elevated errors or rising response times, then ease back up as things recover.

If your server becomes persistently unavailable, the test stops and reports it rather than continuing to load a struggling system.

Penetration testing an application you don’t own is unlawful, so NIMIS will not test any target until you have proven you control it. Verification is quick: you place a short verification token on your site (either as a meta tag on the page or served from a /nimis-verify path) and NIMIS confirms it.

If any target fails verification, the application stays locked and no test can run. It protects you, protects others from being tested without authorisation, and gives us both a clear record of authorisation.

You’re welcome to test an application you run on a third-party host, but it’s your responsibility to ensure you have permission to conduct security testing on that platform, as some providers require prior authorisation. NIMIS only ever tests the domains and subdomains you’ve verified you own, so testing stays confined to your own application.

NIMIS tests your application over the public internet, so the environment needs to be reachable. To keep everyone else out, NIMIS supports a custom security header: you choose a header name and secret value in the dashboard (stored encrypted), NIMIS attaches it to every request, and you configure your infrastructure or WAF to only allow traffic that carries it.

That lets you stand up an internet-facing staging environment that only NIMIS can reach. It also doubles as a clean way to allowlist NIMIS past rate-limiting or bot-protection rules.

We strongly recommend against testing in production (run NIMIS against a staging or pre-production environment that mirrors it instead), though ultimately that choice, and the responsibility for it, rests with you. Security testing exercises real functionality, and some actions are inherently state-changing, so NIMIS is deliberately conservative: genuinely destructive actions are disabled by default and only ever run if you explicitly opt in.

Testing a non-production copy gives you complete peace of mind, and denied paths let you fence off anything you would rather leave untouched.

A CAPTCHA is designed specifically to block automation, and NIMIS does not attempt to defeat or bypass it: doing so would not produce a reliable result and would misrepresent your real security controls.

When NIMIS encounters a CAPTCHA-protected form, it records the form and its endpoint but does not submit it, and it never sends your test-account password to a page it cannot complete legitimately. Your report notes where CAPTCHA-protected forms were present so you know exactly what was and wasn’t covered. If you want those flows tested, you can provide a CAPTCHA-free staging environment.

Yes. Each customer’s data is isolated to their own tenant, and results are only visible to authorised users in your account.

When you need to share outcomes outside your security team (with clients, auditors or regulators), you can generate a redacted report that presents the summary and status without exposing detailed, exploitable specifics. See the reporting section below.

Protecting your data is fundamental to how NIMIS is built. Data is encrypted in transit and at rest, and each customer’s data is strictly segregated into its own isolated tenancy, so it is never commingled with another customer’s.

Access is limited to authorised users in your account, and vulnerability findings are themselves stored encrypted.

No. We do not use your applications, test traffic, or results to train our models. Your data is used to run your test and produce your results, nothing more.

Yes. Each test runs in its own segregated, isolated environment, so one customer’s testing can never affect another’s. Combined with per-tenant data isolation, this keeps your engagement contained from start to finish.

When a test completes, your results are available in the NIMIS dashboard. Each vulnerability comes with a clear description, its severity, the exact location, step-by-step reproduction, concrete remediation guidance, and supporting evidence. You can also generate a formal report to download or share.

NIMIS is built around proof. Depending on the vulnerability, a finding can include:

• The actual HTTP request and response involved, shown side by side, with one-click “copy as cURL” so your engineers can reproduce it.
• Screenshots captured during exploitation.
• The specific parameter, header, cookie or field affected.
• Ordered reproduction steps and prioritised remediation recommendations.

Yes. You can generate a professional, self-contained report from the dashboard. It is produced as a clean, print-ready document that you can save as a PDF using your browser’s print-to-PDF, and email as a single self-contained attachment, with no external assets required.

A redacted report is a shareable summary version of the full report. It includes the executive summary, coverage statistics and overall findings counts, but omits the detailed vulnerability descriptions, reproduction steps, technical evidence and remediation specifics.

It is designed for sharing with external parties (clients, auditors, regulators) who need assurance that testing was performed and an overview of the outcome, without being handed a step-by-step guide to any unremediated issues. The full report remains available to your authorised internal team, and both versions are marked confidential.

Each finding is rated using an industry-standard risk taxonomy, on a clear severity scale: Information, Low, Medium, High and Critical. Lower-severity and informational items are grouped together to keep the report readable, while Medium-and-above issues are called out individually so the things that matter most stand out.

Yes. NIMIS integrates with the collaboration tools your team already uses:

• Slack and Microsoft Teams: notifications when vulnerabilities are found.
• Jira: automatically raise tickets with the details, severity and reproduction steps.

It’s built into every plan. A one-off plan includes two tests: the initial test to find vulnerabilities, and a re-test to validate that the issues you’ve fixed are genuinely resolved. A monthly subscription includes two tests every month, so you can find and confirm fixes continuously. See “Do you offer one-off and ongoing plans?” below.

It depends on the size and complexity of the application. A small web app typically completes in around an hour; a very large or complex application can take up to about 24 hours.

NIMIS can test all your apps at the same time, any time, so a large test doesn’t hold up others. That breadth of on-demand coverage simply isn’t achievable within a fixed, per-engagement security budget. The number of applications and concurrent tests available to you depends on your plan. Talk to us about your needs.

NIMIS supports multiple users per account with role-appropriate access. The number of seats depends on your plan. Get in touch and we’ll help you find the right fit.

NIMIS is offered on a plan basis rather than the fixed, per-engagement fee of a traditional pentest, so you can test as often as you need at a predictable cost. For context, a single traditional penetration test typically costs around $20,000; a NIMIS plan lets you test continuously for a fraction of that. See our pricing page for current plans, or contact our team and we’ll help you find the right fit.

View pricing →

Yes. You can run a one-off engagement or subscribe to an ongoing plan that keeps testing in step with your release cycle. Whichever you choose, every plan includes two tests: an initial test to find vulnerabilities, and a follow-up test to validate that your fixes are effective.

View pricing →

A traditional manual pentest is typically a scheduled, fixed-scope engagement priced per project and delivered once a year. NIMIS gives you thorough, repeatable testing at a predictable cost, without per-engagement scheduling or scoping overhead.

Crucially, you can test every one of your applications whenever you need to, giving you a breadth and frequency of security coverage that a fixed security budget can’t stretch to. Many organisations use NIMIS for that continuous, broad coverage while reserving specialist human testers for periodic deep-dive work. The two are complementary, and we’re happy to talk through where NIMIS fits alongside your existing program.

Absolutely, we’d welcome it. If you’d like a walkthrough, have questions about your specific environment, or want help scoping your first test, get in touch and we’ll arrange a demo.

Book a demo →

It’s quick. Most customers start their first test in under five minutes. After creating an account, you register your application, verify ownership, set your scope and (optionally) your test accounts, then run your first test. If you’d like a hand, contact us and we’ll guide you through it.