In development. Not yet available.

Security testing
that has to prove what it finds.

iast.ai combines Interactive Application Security Testing with AI.

A sensor inside the running application observes what your tests actually exercise. The AI has to turn that into proof: evidence that a finding is exploitable, its cause, and a fix that survives a retest.

Built by Yogev Tehen, Web Security Researcher.

Target output Illustrative. Not from a real run.

SQL injection in order sorting

Exploitable Fix verified

RequestGET /orders?sort=

Sinkdb.query()

Evidence

The injected sort value changed the query structure. The response returned rows from another account.

Cause

The column name is interpolated directly into the SQL query. The allowlist checks the sort direction, not the column.

Fix

Map the sort parameter to an allowlisted column before building the query.

Retest

Same request replayed against the fixed build.
Attack no longer works.

How it is meant to work

IAST is not new. Earlier tools asked teams to accept deployment friction and still triage what they found by hand.

Verified, retested findings solve the triage problem. Friction is still an open question.

  1. Observe

    A sensor inside the application watches requests, data flow, and sinks while your tests run. It sees what actually happens, not what a pattern suggests.

  2. Verify

    The sensor shows that tainted data reached a sink. The AI must show, with evidence, that the path is reachable and exploitable from outside the application.
    That is the bet, and it is not proven yet.

  3. Fix

    Each verified finding comes with its cause and a proposed fix. The original request is replayed against the fixed build before the finding is closed.

Open questions

Three things an application security engineer will ask first, answered honestly.

Supported runtimes
Not yet announced.
The first release will state them up front.
What leaves your environment
To be documented before any pilot.
Requests and sink data can contain secrets, so the default has to be nothing.
Safe verification against a live app
Being designed.
Verification runs only within a scope you define, and against test environments first.

If you run application security for a team and have opinions on these questions, that is the conversation worth having.

Message Yogev on LinkedIn