• 

  Finance OAuth overview

• 

  Endpoint Malware

• 

  Github Supply chain

• 

  Workday Payroll

• 

  Snowflake data exfil

• 

  Ransomware threat

ARES - Cyber Decision Engine

Inspiration

The idea for ARES came from a simple frustration: security teams already have plenty of alerts, but alerts do not tell you what to do next.

During an incident, evidence is usually scattered across identity logs, endpoint tools, email systems, cloud platforms, and asset databases. Some facts are confirmed, some are assumptions, and some are still unknown. Someone still has to decide which action will reduce the risk without unnecessarily disrupting the business.

I wanted to build something focused on that decision.

ARES does not try to replace the incident commander. It organizes the evidence, models how the incident could reach important assets, compares the available responses, and gives the human approver a clear explanation of the tradeoffs.

What ARES does

ARES starts by bringing synthetic incident evidence into one consistent format while keeping the original source and citation ID.

It then separates confirmed observations from derived conclusions and open questions. I considered this especially important because an AI system should not quietly turn an assumption into a fact.

From those claims, ARES creates a causal attack-path graph. The graph connects identities, sessions, credentials, endpoints, cloud services, business processes, and possible impacts. It then calculates which paths each response would interrupt.

ARES compares the available actions using coverage, disruption, urgency, reversibility, and evidence strength. The highest-ranked response is shown together with the runner-up, its operational impact, and any specialist disagreement.

Nothing is executed automatically. A human must review and approve the response before ARES runs a simulation on a cloned copy of the graph. The result shows which paths were blocked, what exposure remains, and what the team should verify next.

The demo includes several synthetic incidents, including OAuth compromise, endpoint malware, ransomware, GitHub workflow abuse, Snowflake data exfiltration, and Workday payroll tampering.

How I built it

I built the decision engine in TypeScript and kept the important calculations deterministic. The engine owns the evidence, claims, graph topology, path enumeration, scores, rankings, approval state, simulation results, and final receipt.

The interface is built with React and Next.js. I designed it as a single decision cockpit so an analyst can see the situation, exposure model, recommended response, and expected outcome without jumping between several dashboards.

I used Codex throughout the project, not just for generating isolated pieces of code. It helped me design the data contracts, implement the graph and scoring logic, build synthetic scenarios, write validation tests, diagnose interface problems, and iterate on the guided demonstration.

One useful example was the attack-path graph. The first layouts looked acceptable on my screen but became difficult to read at other widths. I worked with Codex to trace the problem to the graph geometry, adjust the spacing, and test it across several viewport sizes.

GPT-5.6 provides the qualitative specialist layer. It can interpret the evidence, challenge the recommended response, explain assumptions, and present the result for different audiences.

I deliberately limited that role. GPT-5.6 cannot create evidence, invent citations, change the graph, rewrite a score, approve an action, or modify the simulation result. Those parts remain controlled and validated by the deterministic engine.

Challenges I faced

The hardest part was deciding how much authority to give the AI.

It would have been easier to ask a model to read the incident and generate a recommendation. That would also make it difficult to explain exactly where the numbers came from or reproduce the decision later.

I chose a more structured approach. The model can contribute judgment and disagreement, but the underlying facts and calculations remain locked.

The graph visualization was another challenge. Realistic incidents quickly produce crowded diagrams, and edge labels can overlap the node cards. I had to balance readability with the amount of information shown on one screen.

I also ran into an unexpected problem with the guided demo. Some overlay screens appeared above the demo controls, which made the controls impossible to click. Fixing it required changing where the presenter bar was rendered and establishing a clear layering order.

Building the counterfactual scenario was especially useful. When endpoint malware is confirmed, the graph expands from three paths to seven and the recommended action changes. That helped prove that ARES was actually responding to evidence instead of always returning the same answer.

What I learned

The main thing I learned is that explainability is not just a paragraph generated after a decision. It starts with knowing who or what owns every fact, score, and state change.

I also learned that disagreement should not automatically be removed. A dissenting specialist may be pointing to an assumption that the main recommendation overlooked. ARES keeps that disagreement visible for the human approver.

Finally, I learned how valuable a single canonical decision record can be. The SOC, CISO, and executive views use different language, but they all come from the same evidence and result.

What’s next

I would like to add signed decision receipts, configurable approval policies, and controlled integrations with real security platforms.

I also want to build a replay environment where teams can compare historical decisions and examine how different evidence would have changed the recommended response.

My goal is not fully autonomous incident response. It is to help people make difficult security decisions faster, with clearer reasoning and a record they can defend afterward.

Links

• Try the live ARES demo
• [Watch the video demonstration] (https://youtu.be/daDI1OWOmj

Built With

• agents
• ai
• attack
• codex
• cybersecurity
• decision
• drizzle
• explainable
• gpt-5.6
• graph
• human-in-the-loop
• incident
• intelligence
• knowledge
• next.js
• openai
• operations
• orm
• react
• response
• security
• typescript
• vite
• workers