E-Tap

Inspiration

Phishing starts most attacks, and a tool that judges emails is only as good as its detection rules. Those rules need constant care: every new attacker trick needs a rule, tests, a review and security checks. That upkeep is exactly the work that happens after the code is written, which is what this hackathon is about, so we automated it with GitLab Duo Agent Platform.

What it does

E-TAP is an open-source (MIT) email threat analysis platform. Give it a suspicious email (an .eml/.msg file, or open it in Gmail through our browser extension) and it returns a plain-language verdict: how risky it is, why, and what to do, with the evidence behind it. It checks headers, links and attachments, looks up threat intelligence, and can open attachments inside the user's own virtual machine, where 53 original detection rules judge what they do.

The automation keeps those rules maintained, from issue to merge:

Plan and create. An issue describes a gap (in the demo: scripts that read the Windows clipboard). An issue template assigns it to GitLab's Developer agent, which, guided by a project skill we wrote that teaches it our rule format, writes one new rule with tests and opens a draft merge request.
Verify and secure. Our CI pipeline runs the backend, frontend and extension tests, a dedicated job for rule changes, and GitLab's secret, dependency and code scanning plus a licence check.
Review. Our own flow starts automatically when the merge request opens. It uses two agents on purpose: one reads the change and cannot write; the second sees only its summary and can only post a comment. Neither can approve, merge or run code, and the review always lists what it did not check.
Fix. The review's points go back to the Developer agent, once, and it applies them.
Merge. A person decides. This is the Supervised level, on purpose: E-TAP decides what counts as phishing, so a person owns what ships.

We also wrote flows for failed-pipeline triage and outage response, and triggers that decide when each flow runs.

How we built it

Duo Agent Platform: GitLab's Developer agent, three custom flows (merge request review, pipeline triage, outage response), triggers, an issue template, and a project skill (skills/etap-detection-rules).
Pipeline: .gitlab-ci.yml with tests, GitLab's SAST, secret and dependency scanning, and an image build.
E-TAP itself: Python and FastAPI, a React dashboard, a Gmail browser extension, MongoDB, XGBoost triage, and an optional VM-based sandbox using Sysmon.
Also in the repo: an MCP server that exposes E-TAP's analysis to agents (built and tested, not used in the video).

Challenges

The agents looped. Our first full run chained review, fix and review again three times, because the Developer's reply mentioned the reviewer, which started another review. It stopped only when a session failed. We turned off the trigger that closed the loop and added a rule to the reviewer: it hands points on only when a merge request started the review, never when a comment did.
Real limits, reported honestly. The Developer agent could not run pytest in its environment, and a session once failed on a GitLab lock error when two agents overlapped. Our outage-response flow could not reach the internet from its sandbox, so it said "cause unknown" instead of guessing.
Licensing. We removed 157 third-party rules under a non-open-source licence and wrote 51 original MIT ones, each with tests.
A deliberate human step. Letting agents merge their own detection rules felt wrong for a security tool, so the merge stays with a person.

Accomplishments we're proud of

A real issue-to-merge chain that runs on our own public repository, an AI review that is honest about what it did not check, and a pipeline that kept 291 tests green throughout.

What we learned

Agents are most useful when they are boxed in: separate reading from acting, give each the fewest tools it needs, and put a person at the one decision that matters.

What's next

Run the sandbox on a real VMware machine, add a monitoring probe that creates outage issues automatically, and consider widening autonomy once the review has a longer track record.