AI agent and human expert: how a Sipar review works

The two questions we hear most about a Sipar review are "Will an AI agent see our code?" and "If AI does everything, how far can we trust the result?" This article describes the process openly from start to finish: who does what, at which stage and within which limits.

The short answer: the Claude AI agent speeds up the review, and a human expert verifies every finding and is responsible for the fix. Access is read-only, and the work is done under an NDA.

Why both are needed

An official cybersecurity expertise usually finds two kinds of problems.

The first kind are typical, recurring issues: missing security headers, outdated libraries, open ports, insecure configuration, http:// links left in code. Finding them means reviewing many files and settings quickly and consistently. This is where an AI agent is strong.

The second kind are logic issues: can a user see someone else's data, does a "success" page appear before a payment is confirmed, can an action be performed in the wrong state. These require understanding the product's business process. Here a human expert's manual review is decisive.

Our own product's expertise had both kinds: alongside typical findings such as open ports and information disclosure, there was a business logic flaw — a payment success page shown before the payment was confirmed. That is why our process combines both approaches.

Stage 1: request and NDA

Everything starts with a request: what the product is (website, portal, mobile app), which technologies, which expertise you are preparing for and what the timeline is.

Before work begins, a non-disclosure agreement (NDA) is signed and the scope of access agreed:

• read-only access to the repository;
• access to a test environment, if needed;
• APK/IPA files for a mobile app.

There is no need for access to the production database, real user data or write permissions, and we do not ask for them.

Stage 2: automated and AI scan

At this stage, automated tools and the Claude AI agent review the product broadly:

• Code — dangerous patterns, places missing authorization checks, keys and secrets left in code;
• Configuration — framework settings, debug mode, trusted proxy and host settings, and for mobile apps the manifest and Info.plist;
• Dependencies — library versions with known vulnerabilities;
• HTTP headers — CSP, HSTS, X-Frame-Options and others;
• Server — open ports, TLS settings, unnecessary services.

The result is a list of findings, each mapped to an OWASP Top 10, ASVS, MASVS or CWE category. But it is not the final report yet. The AI agent sometimes produces false positives or misjudges severity. That is why the next stage is mandatory.

Stage 3: manual review

The expert does two things.

First, they confirm or reject the AI findings. Each one is re-checked: is it actually exploitable, under what conditions, and how severe is it.

Second, they manually test what automated tools find poorly:

• Business logic — can steps be skipped or actions performed in the wrong state in processes such as payment, ordering or applications;
• Authorization — can an ordinary user reach administrator functions;
• IDOR — can changing an identifier in a request return another user's data;
• File upload — are file type, size and storage location properly restricted, and can an uploaded file be executed.

Stage 4: fixing

Once findings are confirmed, the closing stage begins. There are two formats, depending on what suits the client:

• Patch or pull request — we prepare the fix, and your team reviews and accepts it. The code stays under your control; we do not change anything directly.
• Guidance — if your in-house team prefers to change the code itself, each finding comes with precise instructions: which file, which setting and why.

Server settings (firewall, closing ports, putting the admin panel behind an IP allowlist) are usually provided as guidance and carried out by your administrator.

Stage 5: re-scan and readiness report

After the fixes are in, the checks from stages 2 and 3 are run again: is each finding really closed, and did the fix introduce a new problem.

At the end, you receive a readiness report: what was found, what was closed, what remains (if anything) and why. For a mobile app, it also includes practical details such as the file to submit and its checksums.

A readiness report is not an official certificate. Only the official expertise issues a certificate or conclusion. We prepare your product for it and close known issues in advance.

The limits of this approach

What should be said plainly:

• AI speeds up the review but does not replace the expert. Every finding is verified by a person.
• No review guarantees finding every vulnerability. We work to the standards the expertise checks (OWASP, ASVS, MASVS) and aim to cover them consistently.
• Access is read-only and under an NDA. Your data does not leave the agreed scope.

Security scan

Want to see the process on your own product? Request a security scan. In the first stage we look at your product's overall state and tell you which areas to focus on before the expertise.