Sirius Argus: security inside the ML pipeline
My architecture contribution to Sirius Argus: the ML model lifecycle, a single release point, a manual gate and real screens from the public project.
The task
Sirius Argus began as the final team project of the “AI Technology Security” programme by Sirius and Alfa-Bank. We started on 1 June 2026 and defended it on 6 June.
The goal was to connect security with the model lifecycle: data preparation, training, artifact storage, release and operations. A set of separate scanners does not answer which model may be released and who is responsible for that decision.
The training case considered a closed bank environment receiving an external model, for example from Hugging Face. The architectural goal was to check the artifact before release, link findings to the approval decision and keep control afterwards.
The key question for me: if a model passed the checks, how do we make sure that this exact artifact went to production, and that the decision was made by someone with the right authority? That links ML security to ordinary backend work: object identity, action authorisation and change history.
Architecture
Argus is built around a single point of release control. A model passes through a control plane that checks access, scan results and release conditions.
Protection is split into four areas: asset discovery, supply chain security, model validation and runtime control.
| Component | Responsibility |
|---|---|
| FastAPI control plane | Permission checks, gates and registries, common interface |
| MLflow and MinIO | Model versions and artifact storage |
| PostgreSQL | Asset links, findings, decisions and audit |
| Redis | Scan queue and event delivery |
Components and network boundaries are described in the project architecture.
My role
My contribution focused on the architecture proposal:
- the Zero Trust concept and a single entry point;
- the role model and access separation by data sensitivity;
- the approach to model audit and threat analysis;
- help with the presentation and coordinating pre-defences.
I proposed treating the development and production environments separately: they have different users, assets and ways of influencing the model, with a verifiable transition between them that controls version and access rights. Technical implementation of the platform is the team’s shared result.
How checks connect to release
The registry stores models, versions and related assets. Scanning creates findings tied to those assets. Before release the system checks policies; critical versions require a human decision. The decision is bound to the artifact’s hash, and the author of a request cannot approve their own release.
A signature confirms origin and integrity. Behavioural properties need their own checks: a correctly signed version can still contain unwanted logic, so signing is used together with scanning and validation.
Showing that protection works
| Check | Expected behaviour |
|---|---|
| Dangerous serialised artifact | Blocked before deserialisation, critical finding created |
| Critical version without approval | Release stays blocked |
| Action outside the role’s rights | Access denied and event recorded |
| Query series resembling extraction | Rate limiting and a finding in the shared flow |
These scenarios give testable conditions for specific threats; they do not promise detection of every attack.
Result
The team project was defended at Sirius, and development continued in the public Sirius Argus repository. The demo uses three non-generative sklearn models on the iris dataset.
This work connected backend, access architecture and ML security for me: security became part of how decisions about a model are made.
