Understand the failure mode
I start with how access, credentials, or systems can fail, not with a product category.
ashwin@security:~$ cat ~/.config/ashwin/profile.toml
Hi, I'm Ashwin.
I'm a Lead Security Engineer in New York, currently helping a fast-growing engineering organization adopt AI without losing control of identity, data, and cloud infrastructure.
I lead the Corporate Security team and own the platforms that govern identity, access, and secrets. I came up through application and product security, and I still write the tools and run the incidents myself.
Ashwin's profile
[work]
- role
- = "Lead Security Engineer"
- leads
- = "Corporate Security"
- focus
- = ["identity", "access", "agents"]
[off_duty]
- events
- = ["CTFs", "DEF CON"]
- sports
- = ["pickleball", "football"]
- coffee
- = "cortados / Stumptown"
- keyboard
- = "IQUNIX L80"
- switches
- = "brown switches"
- terminal
- = "tmux"
01 / how I think
Start with the risk. Then build.
I care less about adding another tool and more about making the right security boundary real.
Build the boundary
I prefer controls enforced by architecture over policies that depend on people remembering them.
Learn from evidence
I use effective-state data and incidents to improve controls after they meet real users.
02 / things I've built
Projects I've worked on, problems I've solved.
Identity and access
Access policy API and source of truth
Persona-based access control
Self-service privileged access requests
Scoped secret writes
Just-in-time database access
Access certifications
Machine credential inventory
Breakglass review automation
AWS least privilege
API authorization cleanup
Access governance metrics
Corporate and infrastructure
Zero-trust network access ownership
Migrating teams off legacy VPN
MDM enforcement
Fleet-wide laptop queries
Device offboarding automation
Audit log pipelines
SAML certificate rotation
Application and product security
WAF across every public endpoint
Static analysis for every Go service
Vulnerability triage with security champions
S3 public access remediation
Redacting auth headers from WAF logs
03 / how I lead
Security culture is built, not announced.
Working in a hyper-growth engineering organization taught me that building a security-first culture takes trust, empathy, and creative controls, not more gates. I build secure paths that work better than the workaround, so engineers can move quickly while the company's risk goes down.
My job as a lead is to create that environment while staying close enough to the implementation to know when it is not working.
04 / how I got here
How I ended up in security.
I studied computer science and systems through a Computer Engineering degree in Pune, then Cyber Security Engineering at USC. That path took me from software and embedded systems to failure modes, trust boundaries, and adversarial thinking.
University of Southern California ↗
M.S. Cyber Security EngineeringFocused on engineering and operating secure information systems: secure applications and networks, security policy, cryptography, key management, and system assurance.
University of Pune ↗
B.E. Computer EngineeringBuilt foundations in algorithms, programming, computer architecture, software design and testing, and practical systems engineering.
05 / a little more
I enjoy ambiguous security problems: the ones where the risk is real, ownership is unclear, and the answer has to work for engineers as well as Security.
I still stay close to implementation. Outside work, I rotate between CTFs, pickleball, football, cortados, and trying the latest terminal tools. Currently deep in a terminal-tooling rabbit hole.
More about me →06 / say hello
Want to compare notes?
If you're working through a hard security or identity problem, I'm always interested in how other teams approach it. Access models, privileged access, endpoint investigations, or how to make any of it survive real engineers. Most of my thinking right now is on agentic security: what an AI agent should be allowed to do, whose identity it acts under, how its access expires, and how you find the ones already running on your fleet.