Enji GuardWhat it runs
Web pentest Autofix is part of Enji Guard's improvement loop. The run takes one verified surface and tries to move it forward after audit or product evidence makes the next step clear.
That does not give Enji Guard open-ended permission to rewrite the repository. The run keeps the work small, records why this candidate was chosen, and produces output a person can review before anything lands.
Its closest audit source is Web pentest audit, but the improvement still checks the current repository before proposing work.
Starting evidence
The latest Web pentest context for the same repository and exact URL, the official findings artifact it points to, the current default branch, GitHub or GitLab issue and pull-request history, and the requested write mode.
Earlier Enji Guard context helps only when it still matches the target. The run revalidates access, looks for duplicate GitHub work, and treats stale or missing evidence as a reason to stop rather than a reason to guess.
Allowed change
The run is tied to one repository and the exact website the Web pentest audit tested. It works on one confirmed finding at a time and never contacts the website to reproduce or extend the exploit; only repository-local, non-destructive checks are allowed.
- One issue created, reused, or updated with a redacted defensive problem statement.
- One dedicated branch and pull request for a bounded defensive change in issue-and-PR mode.
- A report-only outcome when the source context, target, or write mode does not match.
One focused run keeps the change small enough to review.
Take one confirmed finding from the Web pentest audit of a verified website, create or reuse a single issue, and open a bounded fix pull request only when the change is defensive and verifiable.
Boundaries
Enji Guard improvements stay useful because they are constrained. A run stops or falls back to a report when repository access, target scope, source context, or the write path is not clear enough.
- It does not run a new pentest or send exploit traffic to the live site.
- It does not fall back to Security audit findings or a generic latest findings list.
- It does not merge, deploy, or push to the default branch.
Candidate selection
Enji Guard prefers the finding a person selected when it still matches the source exactly; otherwise it takes the first ordered candidate that remains current after revalidation. A stale, duplicate, already fixed, or unfixable selection is reported as that outcome instead of being swapped for another finding.
- 1
Resolve the target
Read the repository identity, selected improvement, and any linked website or paired audit context.
- 2
Validate current state
Check repository access and current files before relying on earlier Enji Guard evidence.
- 3
Deduplicate existing work
Read relevant GitHub issues and pull requests so Enji Guard does not repeat stale findings or rejected fix patterns.
- 4
Pick the smallest useful candidate
Prefer one improvement that can be explained, reviewed, and verified.
- 5
Record the stopping reason
If the run cannot safely write, the report explains whether the outcome is report-only, issue-only, or blocked by missing evidence.
Outputs
The final report names the repository, the exact website, the source finding, the issue or pull-request outcome, the repository checks that ran, and states that the Web pentest score stays unchanged until the site is redeployed and tested again. Output choice depends on the runbook and product mode. The report remains the durable record even when the visible result is a GitHub issue or pull request.
| Output | When it fits |
|---|---|
| Report | The run inspected the target and needs to record the outcome, limitation, or verification. |
| Issue | The evidence is real but the fix needs product, security, or architecture judgment. |
| Pull request | The candidate is narrow, reviewable, and has a credible verification path. |
Booking lookup returns another customer's reservation on the verified staging site
Issue opened; ownership check proposed in a pull request after repository tests
Product surface
Enji Guard exposes improvements from the audit or repository surface, not a separate code-writing workspace. The same action can appear in the control panel, recent activity, and report history after a completed run.
Review and rerun
An issue or an unmerged pull request leaves the Web pentest score where it was. The site has to be redeployed and the Web pentest audit run again before the score can reflect the fix.
This is the same health model as the audit pages: Enji Guard improves a concrete surface, a person reviews the output, and a later audit or improvement rerun evaluates the new revision. The maintained state is the green zone, not an untouched backlog of findings.