As AeglysAI develops from an open-source research initiative into a broader engineering community, its creator, technology architect and researcher Shubh Prabhat, is preparing a series of community hackathons designed to give students, researchers, and engineers an opportunity to explore adaptive-security problems through hands-on technical work.
The planned challenges move through three connected engineering themes: adaptive authorization, behavioral risk intelligence, and resilient automated response.
Rather than treating the hackathons as isolated coding competitions, the initiative is being designed around a broader objective: opening technical questions within AeglysAI to engineers with different backgrounds, allowing them to build, test, challenge, and improve ideas through reproducible engineering.
Why Open Research Needs External Engineers
AeglysAI explores how intelligent capabilities can participate in security and operational decisions while remaining constrained by deterministic engineering policies.
That creates questions that are difficult to answer through architecture diagrams alone.
Can behavioral information improve authorization decisions without generating excessive false positives? How should contextual risk influence an access decision? What happens when a risk-evaluation component becomes unavailable? How can an adaptive system explain why it required additional verification or restricted an operation?
For Prabhat, opening such questions to other engineers is a natural extension of open-source research.
A proposed architecture may appear convincing to its creator, but independent engineers can approach the same problem with different assumptions, implementations, and testing strategies. Their work can expose limitations, challenge design choices, and potentially identify approaches that the original system did not consider.
The AeglysAI hackathon initiative is being structured around that principle.
Three Progressive Challenges
The planned series consists of three related challenges rather than three disconnected competitions.
The first, the AeglysAI Adaptive Authorization Challenge, focuses on moving beyond purely static access control. Participants will explore concepts including RBAC, ABAC, Zero Trust, contextual risk, and explainable authorization.
The second, the AeglysAI Behavioral Risk Challenge, moves toward behavioral signals, anomaly detection, risk scoring, identity context, and false-positive reduction. The engineering question becomes whether changing behavioral evidence can provide useful security intelligence without turning every unusual activity into a threat.
The third, the AeglysAI Autonomous Resilience Challenge, extends the problem toward observability, incident detection, resilient response, and policy-bounded automation.
Together, the challenges follow the broader AeglysAI research cycle:
Observe. Assess. Authorize. Respond.
The progression is intended to help participants understand how individual security mechanisms can eventually become parts of a larger adaptive system.
Foundation and Advanced Tracks
Because the initiative is expected to attract participants with different levels of experience, each challenge is being designed around Foundation and Advanced tracks.
The Foundation track is intended for students, early-career engineers, and first-time open-source contributors. Participants might implement a contextual authorization capability, improve observability, create security tests, or strengthen decision explanations.
The Advanced track is intended to support deeper investigation by experienced engineers, advanced students, and researchers. Projects might examine alternative behavioral-risk models, risk-signal fusion, dynamic thresholds, resilience strategies, or experimental comparisons between authorization approaches.
The objective is not to create a prestige hierarchy between the tracks. Both are intended to address the same broad research questions at different levels of technical depth.
Qualification Through Real Engineering
AeglysAI’s proposed participant qualification process also differs from a conventional programming test.
Applicants will be asked to work with the actual open-source repository. The planned workflow requires participants to fork AeglysAI into their own GitHub account, clone and run the project locally, understand relevant parts of the architecture, and submit a technical observation and improvement proposal.
Participants will work in their own forks rather than receiving direct write access to the official repository.
The qualification process is intended to answer a practical question: Can the participant understand an unfamiliar engineering system well enough to reason about improving it?
Completing qualification will not automatically guarantee selection. Published selection requirements are expected to consider readiness, technical reasoning, curiosity, and the ability to communicate an engineering idea.
Further details regarding the system architecture, implementation methodology, experimental setup, and supporting software artifacts are publicly available through the AeglysAI project website and associated source-code repository.
Independent Judges and Reproducibility
Judging is being designed around technical evidence rather than presentation alone.
The proposed evaluation framework considers areas including technical correctness, security reasoning, architecture quality, reproducibility, innovation, and documentation.
AeglysAI also plans to involve external technical professionals as judges, subject to confirmation and conflict-of-interest requirements. Sponsorship, where present, is intended to remain separate from technical evaluation and winner selection.
Reproducibility is particularly important to the program. Final projects are expected to document their architecture, setup process, implementation, testing, security considerations, and limitations so that another engineer can understand what was built and how the claimed result was evaluated.
Building Community Beyond Competition
The longer-term objective is for useful work to continue after individual events end.
Ideas emerging from hackathons could become research questions, GitHub discussions, documentation improvements, experimental branches, or potential contributions subject to normal project review. A submission will not automatically become part of AeglysAI simply because it participated in a hackathon.
The initiative is also planning technical workshops, architecture discussions, mentor interactions, project showcases, and digital certificates for participants who satisfy published completion requirements.
For Prabhat, the goal is to create something broader than a prize-driven competition: an engineering environment where participants can learn how to evaluate security ideas systematically and where open-source research benefits from perspectives beyond its original creator.
Whether those ambitions translate into a sustained community will ultimately depend on participation and the technical work the events produce. For now, the AeglysAI hackathon series represents an attempt to move adaptive-security research from a repository into a collaborative engineering environment—where ideas can be questioned, implemented, measured, and improved by others.
