AI security researcher and security engineer

Aditya Khanal

How do we build machine learning systems that hold up against attackers, and how do we verify they can be trusted in the first place? I work on that question from the model down to the infrastructure it runs on.

GNN watermarking and model-extraction research at RAI Lab. Security of LLM internals and inference serving. DevSecOps engineer at Bajra Technologies, building detection pipelines and hardened infrastructure. Computer engineering, Pulchowk Campus. Kathmandu, Nepal.

5 × 3GNN watermarking methods tested across graph datasets
3open LLM-serving security problems identified
~40%lower mean time-to-detect for high-severity events

Fig. 1 An AI production stack in cross-section: six infrastructure layers I built, then the model and its inference server. Pick an attack to see where it is stopped, or where nothing stops it yet.

Supply chain
Trivy scan at build, Cosign signatures, digest pinning
Admission
Pod Security Admission, CIS Kubernetes Benchmark
Identity
Fine-grained RBAC, Vault short-lived credentials
Network
NetworkPolicy, Neutron tenant isolation, pfSense
Data
etcd encryption at rest, TLS 1.3, HSTS, OCSP stapling
Detection
Wazuh rules on MITRE ATT&CK, syscall audit, forensic logs
Model and inference
Watermark verification, KV cache, quantization, tenant isolation

Six infrastructure layers I designed or configured in production, plus the model layer my research works on. No attack selected.

Research

Lab: RAI Lab, remote
Period: May to August 2025
Status: Manuscript in preparation

Building a defence and properly testing a defence are two very different things, and the second is often done poorly. My research tests ML defences the way a real attacker would.

Training a good model costs data, compute and expertise; stealing one can take nothing more than API access. Watermarks are meant to let the owner prove a copy is stolen. I measured how well graph neural network watermarks survive when the thief prunes, distils or fine-tunes the copy, and found where they stop working. I am writing these findings up for publication.

Threat model

Owner trainsA GNN with a secret watermark embedded during training.
Model is servedPredictions are exposed through a query API.
Attacker extractsQueries the API and trains a surrogate copy.
Attacker laundersPrunes, distils or fine-tunes the copy to erase the watermark.
Owner verifiesTests the suspect model for the watermark. Below 50%, ownership can't be proven.

<50%

The verification rate at which current GNN watermarks become undetectable under removal attacks.

Key finding. The most effective removal attacks are also the ones that best preserve the model's usefulness. The attacker loses almost nothing by erasing the watermark, so defending is harder than it looks.

GNN watermarking robustness study

I implemented five GNN watermarking methods and evaluated them across three graph datasets. For each one, I measured how reliably ownership could still be verified after pruning, distillation and fine-tuning. The results went upstream to PyGIP, an open-source framework for graph model extraction attacks and defences.

Experimental setup
Watermarking methods compared	5
Graph datasets	3
GNN architectures in the reproduction	5
Removal attacks	Pruning, distillation, fine-tuning
Conditions	Clean and adversarial

Method

Implemented five watermarking schemes in a common framework so results are directly comparable.
Reproduced An Imperceptible and Owner-unique Watermarking Method for Graph Neural Networks, measuring verification accuracy and watermark fidelity across five architectures.
Applied each removal attack to each watermarked model and recorded the verification rate.

Findings

The strongest removal attacks keep the stolen model's accuracy, so the attacker pays little to erase ownership evidence.
Under specific removal conditions, verification falls below 50% and a stolen model can no longer be identified.
Robustness differs widely between methods and attacks, so one clean-condition accuracy number says little.
Proposed design criteria for watermarks that survive laundering.

Contributions to PyGIP

New watermarking defence modules.
A standardized evaluation harness for comparing defences under the same attacks.
Robustness results contributed upstream.

LLM internals and inference security

To find where an attacker really has leverage over a language model, I built its parts myself, then studied how models are actually served in production.

Built from scratch

Tokenization. How raw text becomes the model's input, and where crafted inputs enter.
Attention, in increasing complexity. Showed how a carefully crafted input can shift what the model attends to.
Quantization to compressed integer formats. Showed that compressing a model changes how it responds to inputs in ways not obvious from outside.

Studied in production serving

KV caching and prefix caching
Paged memory management
Batching strategies
Speculative decoding

Open problems this surfaced

Cache timing side channel

When KV or prefix cache entries are reused across users, response timing can reveal what earlier users asked. Existing LLM security analyses rarely account for it.

Compression changes robustness

Quantizing a model to run on cheaper hardware changes how it responds to adversarial inputs, so the robustness of the original model may not carry over.

Isolation between tenants

When one model instance serves thousands of users at once, keeping them isolated becomes a security property, not just an engineering one.

Earlier work: attacking a GNN in deployment

2023 to 2024. GNN, BERT, Node.js. Source on GitHub

I built a graph-based recommendation system on user–product interaction graphs, then treated it as a target. This is where my interest in graph ML security started.

Data poisoning. Analysed how node injection and edge manipulation shift recommendations.
Model extraction. Studied how much of the model an attacker can copy from its outputs.
Prompt injection. Measured attack success against the BERT-based semantic query component as a function of perturbation magnitude.

Where AI meets security next

A security system that is robust but cannot be audited, or a model whose behaviour cannot be verified, is not truly trustworthy. These three directions depend on each other.

LLM security and adversarial robustness

Prompt injection, backdoors planted through fine-tuning, manipulation of retrieval-augmented generation and jailbreaking are not yet well understood theoretically.

What kinds of inputs reliably cause unsafe behaviour, and can that be stated formally?
How does fine-tuning on malicious data quietly degrade a model's alignment?
How do we verify that a deployed model is actually the one it claims to be?

Adversarial ML for security systems

Deep learning now runs intrusion detection, malware classification and anomaly detection, so the security tools themselves become targets.

How do ML detectors fail under realistic attacker models: crafted evasion samples and slow poisoning?
Quantization and serving optimizations change the model the attacker actually meets. Which robustness guarantees survive?

Model integrity and provenance

Proving a deployed model hasn't been copied, modified or fine-tuned on adversarial data matters for any large model in a high-stakes setting, well beyond GNNs.

What can and cannot be verified about a model under realistic constraints?
Which design choices make models easier to protect and audit?

Work

Role: DevOps Engineer / DevSecOps
Company: Bajra Technologies, Kathmandu
Since: January 2024

Two years of production security taught me that real attackers don't behave the way most defence systems expect. The gap between how a system is designed and how it performs under pressure is where the interesting problems live, and it is where my research questions come from.

Threat detection and testing

Real-time detection pipeline

Problem: High-severity attacks took too long to surface.
Work: Wazuh SIEM rules mapped to MITRE ATT&CK: lateral movement, privilege escalation, credential access.
Result: MTTD for high-severity events down ~40%

Security posture assessment

Problem: Servers and network devices had drifted from a secure baseline.
Work: Systematic CIS Benchmark assessment, then designed and applied remediations.
Result: 15+ hosts at full CIS Level 1

Web application pentesting

Problem: Applications about to ship had untested attack surface.
Work: Manual testing with Burp Suite and OWASP ZAP, documented against the OWASP Top 10.
Result: SQLi, IDOR and broken auth fixed before production

Container threat modelling

Problem: Docker and Kubernetes runtime exposed more than needed.
Work: Static image analysis, RBAC enforcement, NetworkPolicy segmentation, CIS Kubernetes Benchmark validation.
Result: Smaller exploitable surface at the runtime layer

Covert channel hunting

Problem: Anomalous traffic suggested hidden communication.
Work: Wireshark packet evidence correlated with SIEM alerts.
Result: Channels identified and blocked in pfSense

Shift-left scanning and email

Problem: Defects reached late stages; the domain could be spoofed.
Work: SonarQube and Trivy SAST/DAST in CI/CD. SPF, DKIM and DMARC on a self-hosted Mox server.
Result: Defects fail the build; spoofing surface closed

Cloud infrastructure and systems security

Hardened Kubernetes

Threat: Compromise of any single layer of a self-hosted cluster.
Control: Multi-master kubeadm with etcd encryption at rest, Pod Security Admission, fine-grained RBAC, syscall auditing, Cosign image signing.

Multi-tenant OpenStack

Threat: Cross-tenant traffic and over-privileged services in a private cloud.
Control: Nova, Neutron, Cinder and Swift with Neutron segmentation, least-privilege Keystone RBAC and zero-trust security groups.

Dynamic secrets

Threat: Leaked long-lived credentials.
Control: HashiCorp Vault short-lived database credentials, automatic rotation and audit trails, reducing the blast radius of a leak.

Forensic log pipeline

Threat: Incidents that can't be reconstructed.
Control: Prometheus, Grafana and central log aggregation correlating compute, network and application events into attack timelines.

Supply-chain controls

Threat: SolarWinds-class tampering with build artefacts.
Control: Trivy scanning at build time, image signing and digest pinning so a tampered image is never deployed.

Transport security

Threat: Downgrade and interception between services.
Control: TLS 1.3 enforced via Nginx, HSTS, OCSP stapling, strict cipher suites and managed certificate lifecycle.

ATT&CK tactics covered

MITRE ATT&CK tactics with detections or controls
Initial Access	Pentest findings fixed pre-release; SAST/DAST in CI/CD; SPF, DKIM, DMARC
Privilege Escalation	Wazuh rules; Pod Security Admission; least-privilege RBAC
Credential Access	Wazuh rules; Vault dynamic secrets; etcd encryption
Lateral Movement	Wazuh rules; NetworkPolicy; Neutron tenant isolation
Command and Control	Covert channels found with Wireshark and SIEM, blocked in pfSense

Projects

PyGIP contributions

Watermarking defence modules and an evaluation harness for an open-source graph model extraction framework.

Python, PyTorch Geometric. 2025

Graph-based expert system

GNN recommender built and then attacked with data poisoning, model extraction and prompt injection.

GNN, BERT, Node.js. 2023 to 2024

Driver attention monitoring

Real-time drowsiness detection from facial landmarks, evaluated for robustness to occlusion and lighting perturbations, as a safety-critical ML system must be.

Python, OpenCV, MediaPipe. 2023

AI-Tetris

A Monte Carlo Tree Search agent; studied exploration–exploitation trade-offs and policy robustness under stochastic and adversarially perturbed game states.

Python, MCTS. 2022

Education and credentials

Degree: B.E. Computer Engineering
Institution: Pulchowk Campus, IOE, TU
Period: Nov 2019 to Apr 2024

Degree

Bachelor of Engineering in Computer Engineering at Pulchowk Campus, Institute of Engineering, Tribhuvan University, on a full merit scholarship. Graduated with 76.64% overall.

Relevant coursework. Machine Learning, Artificial Intelligence, Computer Networks and Security, Operating Systems, Data Structures and Algorithms, Probability and Statistics.

Honours

Full merit scholarship, 2019 to 2024. Ranked 60th of 9,000 candidates in the national engineering entrance (top 0.7%); full tuition for the whole degree.
Registered Computer Engineer, 2024. Licensed professional engineer by national examination, Nepal Engineering Council.

Certifications

Certifications with verification links
Certified Kubernetes Administrator (CKA)	Linux Foundation / KodeKloud. Verify	Sep 2024
AWS Academy Cloud Computing Architect	AWS Academy. Verify	Sep 2023
Neural Networks and Deep Learning	deeplearning.ai on Coursera. Verify	Jul 2020
Improving Deep Neural Networks	Hyperparameter tuning and regularization, deeplearning.ai on Coursera. Verify	Jul 2020

Toolkit

Security and research: Wazuh, Burp Suite, OWASP ZAP, Wireshark, pfSense, SonarQube, Trivy, MITRE ATT&CK, CIS Benchmarks, HashiCorp Vault
Machine learning: PyTorch, PyTorch Geometric, GNNs, BERT and Transformers, CNNs, OpenCV, MediaPipe, Monte Carlo Tree Search
LLM systems: Tokenization, attention, quantization, KV and prefix caching, paged memory, batching, speculative decoding
Cloud and infrastructure: AWS (EC2, ECS, S3, RDS, Lambda), OpenStack, Kubernetes, Docker, Vault, Cosign, Nginx
Observability and CI/CD: Prometheus, Grafana, GitLab CI, Jenkins, central log aggregation
Languages: Python, C/C++, Bash, Node.js
Databases: PostgreSQL (replication, RBAC), Redis

Contact

Open to research positions and security engineering roles, especially work on LLM security, adversarial ML for security systems, and model integrity.