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.

Automated security tooling follows fixed rules and known signatures. That approach holds up for a narrow, predictable set of cases and falls apart on anything it was not explicitly built to look for. NIMIS reasons about your specific application and makes judgment calls in the moment, closing the gap between what automation can find and what a skilled human tester would pursue.

Behind it sits a purpose-built reasoning engine: an orchestration of models refined specifically for penetration testing, developed over a decade. What is hard to replicate is not the ability to send a request. It is knowing where to look in an unfamiliar application, which of many possible paths is worth following, and when something unusual is genuinely exploitable.

No, and the difference is worth being precise about. Automated tooling compares responses against known patterns and produces a list of things that might be wrong, which somebody then has to work through. NIMIS behaves like a tester: it explores the application, forms a view about what is worth pursuing, and wherever possible proves a vulnerability by triggering its actual effect. That might mean causing a controlled script to execute, receiving an out-of-band callback from your own server, or demonstrating access to data that should have been out of reach.

The distinction is proof versus pattern-matching. It is why the output is a short list of confirmed issues rather than a long list of candidates, and it is the whole reason false positives stay low.

They solve different parts of the same problem, and they work well together. A manual engagement is valuable, 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 and consistency to test thoroughly and to do it again on every change rather than once a year.

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 authorization 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 behavior) 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 is a real difference. Most automated tooling can only reach authenticated areas if you hand it a valid token, and much of it needs 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 determines how to log in, where to go, and what is 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.

Allowed paths work as a carve-out from that. If you deny /admin but still want one area inside it covered, add /admin/list_users to the allowed list: NIMIS will test that path while the rest of /admin stays 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 passphrase, plus a priority if you provide more than one. If an account is protected by multi-factor authentication, you can provide its TOTP secret and NIMIS will generate the one-time codes itself as it signs in. NIMIS uses these to authenticate and explore functionality behind the login.

No. You set a maximum request rate 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 authorization, and gives us both a clear record of authorization.

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 authorization. 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 passphrase 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 authorized 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 authorized 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 prioritized 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 authorized 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.

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 is built into every engagement. A Point-in-Time engagement includes two tests: the initial test to find vulnerabilities, and a second test to validate that the issues you have fixed are genuinely resolved. Continuous testing includes two tests every month, so you can find and confirm fixes on every release. See “Do you offer point-in-time and ongoing engagements?” 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.

We quote directly rather than publishing rates, because engagements are scoped to the organization. What we need to know is how many applications you want covered, how often you want them tested, and what your environment requires.

The structural difference worth knowing is that NIMIS is not priced per engagement. A traditional penetration test is scoped, quoted and delivered as a project, which is precisely why coverage ends up rationed to whatever the budget reaches. Tell us what you run and we will scope it with you.

Talk to us →

Yes. You can run a single Point-in-Time engagement against a specific release or milestone, or move to Continuous testing that keeps pace with your release cycle. Either way, every engagement includes two tests: an initial test to find vulnerabilities, and a second to confirm that your fixes hold.

Talk to us →

A traditional engagement is scheduled, fixed in scope, priced per project and usually delivered once a year. It is a valuable exercise, and its depth depends heavily on the individual operator and the time they are given. NIMIS applies the same rigorous methodology every time, without the scheduling and scoping overhead in front of it.

The practical difference is reach. You can test every one of your applications whenever you need to, which is a breadth and frequency that a fixed testing budget simply cannot stretch to. Many organizations use NIMIS for that continuous, portfolio-wide coverage while reserving specialist human testers for periodic deep-dive work. The two are complementary, and we are happy to talk through where NIMIS fits alongside what you already do.

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 →

Talk to us first, and we will show you NIMIS running against a real application so you can see the output before committing to anything. From there, onboarding an application takes about five minutes: register it, verify ownership, set your scope and test accounts, and run.

Book a demo →