PORTFOLIO
Technical Leadership · AI & Agent Security · Product Security · Cloud IAM
I build security controls, coordinate cross-functional project work, and turn technical risk into engineering and business decisions. My work spans AI-agent security, cloud identity, threat detection, and team delivery.
For recruiters & hiring teams
One background, two ways to evaluate it. Choose the resume most relevant to the role you're hiring for. My projects and full experience are available to everyone below.
For roles focused on designing, implementing, and validating security controls across AI agents, applications, cloud identity, and detection systems.
For security-focused engineering management and technical leadership roles emphasizing team coordination, deliverable reviews, stakeholder communication, and business planning.
Both resumes reflect the same experience, tailored to different hiring priorities.
Leadership highlights
Assigned responsibilities and reviewed deliverables during designated AEROSEC lab phases within a four-member team.
Presented aviation security risks, market positioning, and financial assumptions to Honeywell evaluators.
Developed a 12-month operating plan and compared four commercial security solutions; figures were proposals, not realized funding.
Four security trust boundaries
Selected build 01
Agent tool calls cross an execution boundary where authorization, content risk, egress policy, rate limits, and audit evidence need to be enforced before downstream execution.
Project work: Oct 2025 to Oct 2026. CI figures are from a specific October 2026 Python 3.12 run, not operational detection effectiveness.
The evidence supports implemented controls and bounded test results. It does not claim customer deployment, enterprise adoption, or universal prevention.
Selected build 02
Agent and workload identities can become over-privileged through wildcard grants, iam:PassRole, sts:AssumeRole, weak trust policies, privilege-escalation paths, and missing permission boundaries.
Project work: Apr 2025 to Oct 2026. Static policy analysis does not establish live AWS authorization outcomes.
The evidence supports deterministic static-policy analysis. It does not claim complete effective-permission evaluation, production latency, or runtime authorization guarantees.
Selected build 03
Untrusted model repositories and artifacts can carry serialization, loader, dependency, provenance, and obfuscation risk before a model is loaded.
Project work: Nov 2024 to Oct 2026. Committed regression fixtures are bounded tests, not population-level malware detection evidence.
The fixture results are bounded regression evidence; the benign result covers only four committed samples. Neither is a universal detection or false-positive rate.
Selected build 04
Security teams need more than isolated alerts: related events must become explainable, durable incidents that authorized analysts can investigate and resolve.
Initial ARM/CAN work was verified on main in October 2026 (68 local tests); the newer investigation and security-hardening evidence belongs to separate, unmerged October 27 development branches.
The investigation platform and hardening are currently on unmerged development branches. Healthcare events and incidents in the demonstration are synthetic; MIMIC-IV Demo does not supply audit logs or access authorization. FHIR R4 AuditEvent ingestion is published for review in unmerged PR #50, with 296 local tests reported for Milestone E; hosted CI remains blocked and live hospital ingestion is not claimed. No hospital deployment, HIPAA certification, production readiness, or real-world detection-rate claim.
Engineering case study · development branches
Attack Detection Engine / Aegis HealthSec extends the original ATT&CK and automotive lab engine with a healthcare-focused, deterministic incident investigation workflow. This is a source-backed illustration of locally tested work, not a live SOC connection.
Synthetic clinical access events enter the authenticated FastAPI service. FHIR R4 AuditEvent adapter is available for source review in unmerged PR #50; test events are synthetic.
Existing deterministic clinical-access rules generate explainable findings; benign-control scenarios are checked.
Related findings group by documented identity, organization, resource and time criteria rather than coincidental event proximity.
PostgreSQL retains events, findings, incidents and their relationships through controlled container restarts.
Authorized analysts inspect evidence, add notes, assign cases, and make auditable status changes in the React console.
Incident disposition and history persist. No simulated incident is represented as a real hospital compromise.
Validation boundary: Milestone C documented 212 passing local tests with real PostgreSQL and a Docker investigation scenario on October 27, 2026. Milestone D later reported 280 local tests. Neither count is hosted CI evidence; GitHub Actions remains disabled for this repository.
Data boundary: MIMIC-IV Demo is de-identified clinical context, not an authorization source or a collection of actual cybersecurity incidents. CloudTrail, Sysmon, auditd and multi-language SAST are planned rather than implemented in these PRs.
Application security case study
A white-box security review of the gateway's public attack surface, focused on authentication, authorization, parser abuse, SSRF/egress, availability controls, and evidence generation.
Protected inspection and metrics endpoints require configured API credentials; health/readiness remain orchestration-safe.
Default-deny capability and server policy gates agent tool calls before downstream execution.
Strict JSON-RPC and HTTP parsing rejects malformed requests, duplicate JSON keys, ambiguous framing, oversized headers, and unsupported methods.
Policy checks deny private, loopback, and link-local destinations unless explicitly allowlisted.
Payload limits, rate limiting, circuit breaking, and fail-closed error handling constrain abusive or degraded paths.
Tamper-evident audit records, ECS telemetry, Elastic rules, and SIEM tests make blocked activity reviewable.
Authorized review of my own application using source inspection and automated repository tests. This is not presented as an independent third-party penetration test or production deployment assessment.
How I think
Whether I am thinking as an engineer or as a builder, I keep the same spine: identity, authority, execution, telemetry, and evidence.
Professional & applied experience
Self-Directed Research
Honeywell Aerospace × Arizona State University | Technology Innovation Lab Externship
Arizona State University | Ira A. Fulton Schools of Engineering
Capabilities
Education & credentials
M.S., Information Technology (Security)
Tempe, AZ, USAGPA: 3.87/4.00B.Tech., Computer Science & Engineering
Bengaluru, KA, IndiaCGPA: 8.44/10Academic & AI participation
Arizona State University · Principled Innovation-Infused Learning Engineering
Participated in an ASU Principled Innovation-infused Learning Engineering initiative involving a Generative AI learning assistant designed to support personalized education.
Participation scope: Educational participation; separate from professional employment, internship, and research-service appointments.
Recruiting & collaboration
I'm interested in U.S.-based security engineering and technical leadership roles spanning AI and agent security, product security, cloud IAM, and engineering program delivery.