The fix arrives with the finding
Most security tools stop at the diagnosis. The engineer receives a severity label, a class name and a link to an advisory written for nobody in particular, then spends the first hour working out what any of it means for their code.
Every AIPTx finding carries a remediation summary, the vulnerable and secure patterns side by side in your language, and references.
Fix guidance on every finding · Vulnerable and secure code side by side · Verified by retest
Overview
There is a gap in most security programmes that nobody puts on a slide: the distance between a finding being reported and an engineer knowing what to change.
It looks small and it is not. A finding arrives labelled Broken Access Control, High, CWE-284, with a link to an OWASP page. That page is accurate, well written and general. It describes the class rather than your instance of it. The engineer now has to read it, map it to their framework, work out which of four plausible fixes applies to the code path they are looking at, and decide whether the change breaks anything else.
Multiply that by a backlog and you have the real explanation for why security findings age. Not indifference, and rarely disagreement about severity. It is that each finding carries an unpriced research task, and research tasks lose to feature work every time.
AI Recommendations closes the gap at the point the finding is created. Because the agent exploited the issue, it knows the endpoint, the parameter, the role, the framework and the code path involved, and the guidance is written against that specific situation rather than the general class.
How It Works
- Step 01
It starts with knowing exactly what happened
Recommendations are only specific if the diagnosis is. Because findings are validated by exploitation rather than inferred from a signature, each one already carries the affected endpoint with method, path and parameter, the identity and session state used, the exact request that worked, and the response that proves it.
Guidance is generated against that context. This is why the output can name a parameter rather than a category.
See AI Agent - Step 02
What is produced
Every finding carries a remediation object with three parts:
A summary. What is wrong and what needs to change, in plain terms, written for the person who will make the change, not for the person who found the problem.
A code example. The vulnerable pattern and the secure pattern side by side, in the language of the affected component. This is the part engineers actually use, because it removes the translation step entirely.
References. Links to OWASP, CWE and CVE material for the engineer who wants the underlying reasoning rather than just the change.
- Step 03
It reaches the person who will act on it
Guidance travels with the finding wherever it goes: as SARIF into the editor and the pull request, as a Jira or Linear ticket, as a Slack or Teams alert, or into the Developer Report, a code-centric format with file references and fix examples.
See Integrations - Step 04
The loop closes on evidence
A recommendation is a hypothesis about a fix until something tests it. Push the change and retest re-runs that specific exploit. The finding moves to fixed only when the attack stops working, and the retest history stays attached.
That last step is what separates recommendation from advice.
See Continuous Security Validation
Capabilities
Remediation summary on every finding
The change required, specific to the situation.
Vulnerable and secure code examples side by side
With the language recorded, in the code_example structure.
Standards references
OWASP, CWE and CVE links on every finding, for the engineer who wants the underlying reasoning rather than only the change.
Context-derived specificity
The endpoint with method, path, parameter and full URL; the role and session state; the request and response that demonstrated the issue.
Impact statement
Describing what an attacker gains, so the change can be justified as well as made.
Developer Report
A code-centric report template with file references and fix examples.
Delivery into developer workflow
SARIF into editor and pull request; Jira and Linear tickets; Slack and Teams alerts.
Retest verification
The finding closes when the exploit stops working, not when a ticket is marked done, with retest history attached.
Executive-level recommendations
Reports include strategic recommendations alongside the finding-level guidance, for the audience deciding where effort goes rather than making the change.
Status lifecycle
Open, fixed, accepted, false_positive, with updated_by, timestamps and notes on every change.
Benefits
- 01
The research task disappears.
The engineer receives the change rather than the reading list, which is the single largest hidden cost in remediation.
- 02
Fixes address the cause, not the symptom.
Guidance is generated from the exploited path, so it points at the missing authorisation check rather than at the surface where the symptom appeared.
- 03
Handoff stops being a translation exercise.
Security does not have to interpret findings for engineering, and engineering does not have to interpret advisories for themselves.
- 04
Findings age more slowly.
A backlog item with a known fix and a known cost gets scheduled. One with an unpriced research task attached does not.
- 05
The fix is verified rather than assumed.
Retest establishes that the change worked, which is a materially different claim from a closed ticket.
- 06
Developers learn the pattern, not just the instance.
A vulnerable-and-secure pair teaches the shape of the mistake, which is the only mechanism by which a team stops reintroducing it.
- 07
Two audiences, one output.
Finding-level guidance for engineers, strategic recommendations for the people allocating effort.
- 08
Remediation effort becomes predictable.
When findings include validated impact, clear guidance and estimated scope, teams can plan work based on known effort rather than uncertainty.
What arrives when object-level authorisation is missing.
Illustrative example. Not a customer account.
The agent has confirmed that a low-privilege user can retrieve another account's export via POST /api/v2/exports by supplying a different account_id.
The finding carries:
Location: POST /api/v2/exports, parameter account_id, with the full URL.
Evidence: the exact request sent under the low-privilege session, the response returning the other account's data, and a reproducible curl command.
Impact: what an attacker gains: read access to arbitrary account exports with any authenticated session.
Severity: CVSS 3.1 score with the full vector string, plus the CWE class.
- 01
Summary: the endpoint accepts a caller-supplied object identifier and does not verify that the authenticated principal is entitled to it. The authorisation check must occur server-side, at the point of retrieval, against the session's identity, not against a value the client controls.
- 02
Code example: the vulnerable handler as written, and beside it the same handler with the entitlement check in place, in the language of the service.
- 03
References: the relevant OWASP category and CWE entry.
What happens next. The finding routes to Linear with severity mapped to the team's priority scheme, and appears as SARIF in the pull request when the fix branch opens. The engineer applies the change. Retest re-runs the original exploit against the new code. The response is now a 403. The finding moves to fixed, with the retest recorded and timestamped.
Why this matters.
Between "Broken Access Control, High, CWE-284" and the paragraph above lies about ninety minutes of an engineer's time, repeated for every finding in the queue. That time is the actual cost of a security programme, and almost nobody measures it.
FAQ
Frequently Asked Questions
Are these generic recommendations or specific to our code?
Specific to the finding, because the issue was exploited rather than inferred, so the guidance is generated against the actual endpoint, parameter, role and framework involved.
What languages are supported for code examples?
The code_example structure records the language of the affected component, so the vulnerable and secure patterns are written in the language the finding was validated against.
How do developers receive them?
As SARIF in the editor and the pull request, as Jira or Linear tickets, as Slack or Teams alerts, and in the Developer Report with file references and fix examples.
What if we disagree with the recommendation?
Recommendations are guidance rather than instruction, so apply the alternative fix and request a retest — the finding closes when the exploit stops working, whichever approach you took.
Does the recommendation account for our architecture?
It accounts for what was observed during exploitation — the framework, the code path, the parameter handling — but not for constraints you have not exposed to it, which is why the summary explains its reasoning rather than only stating the change.
How do we know the fix worked?
Retest re-runs the specific exploit and the finding moves to fixed only when the attack fails, with the retest history left attached for whoever asks later.
The platform capabilities behind this feature
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
Sixty criticals is not a plan
Findings ranked by exploitability, impact, asset value and exposure, with the weights published, so the order can be defended.
An agent that changes its mind
Agents that read the response and decide what to try next, which is what makes access control and business logic testing possible at all.
Four audiences, four reports, one assessment
Four report templates for four audiences, five export formats, and a trend line that means something because the methodology does not change.
See what arrives with a finding
Run an assessment and look at the remediation pane: the summary, the vulnerable and secure code, and the references.
No credit card required · Fix verified by retest