I'm a security engineer and architect in Seattle who likes building the thing, not just writing the requirement for it.
My background spans infrastructure, cloud platforms, identity, application security, automation, observability, and federal compliance. I've worked from Linux and network engineering through Azure and AWS architecture, spent time handling Severity-A cloud escalations at Microsoft, and have taken two organizations from Cybersecurity Maturity Model Certification (CMMC) gap assessment through successful certification.
A lot of my work sits where security architecture meets engineering: turning ambiguous requirements into systems, controls, automation, diagrams, and operating models that people can actually use.
This is also a relatively new GitHub for me. I recently retired an older account I'd had since 2016 that had accumulated a pretty random mix of projects over the years. This one is intentionally more focused on enterprise security, application security, cloud, identity, and security engineering.
The projects here explore things like governed coding agents, non-human identity, infrastructure as code, secure application design, policy enforcement, evidence, and the engineering practices behind security controls. I intentionally keep the design decisions, validation mechanisms, and occasional failures visible, not just the finished product.
Most of the larger projects connect through control-plane, while the smaller repositories are experiments, demonstrations, diagrams, and study material.
I build primarily with Python, Terraform, Bicep, PowerShell, cloud-native services, and whatever else is useful for making security repeatable.
If you like the program (control-plane) or the main application (manifest-identity), please give them a ⭐ and let me know!
Read these in this order. Two are applications, one is the rules they are built under, and one is the platform they will run on.
| Project | What it is |
|---|---|
| manifest-identity | An application for reviewing who has access to what across an organization's cloud accounts and directories. |
| build-doctrine | The rules and checks used to govern AI-assisted development across the repositories. |
| secure-expense-mvp | A small application used to exercise application-security controls end to end. |
| control-plane | The AWS estate the applications will run on, defined as code. The design is written and implementation has not started. |
Identity and access governance. Start with manifest-identity, then read its architecture, security model, decisions, and build gates.
Application security. Start with secure-expense-mvp, then read its architecture, design decisions, testing, and security in the development lifecycle sections.
AI-assisted software development. Start with build-doctrine, then read its standards, enforcement, coverage, and decisions.
Cloud security reference material. Start with aws-azure-security-mapping.
Platform engineering. Start with control-plane.
| Project | What it is |
|---|---|
| sample-diagrams | Architecture and process diagrams covering systems, trust boundaries, data flows, security controls, operational workflows, and cross-team handoffs. |
| Project | What it is |
|---|---|
| aws-azure-security-mapping | Ninety-nine AWS security concepts mapped to their closest Azure counterparts, including the cases where the two platforms have no clean equivalent. |
| anki-decks | Seven maintained study decks, 1,262 cards across PowerShell, Python, Kusto Query Language (KQL), Bicep, cybersecurity, the AWS Security Specialty, and compliance frameworks. Each deck has a plain CSV source so changes can be reviewed in Git, and an automated parity check keeps the source and the Anki package in step. |
Certifications
 CISSP |
 Cybersecurity Architect Expert |
Azure Solutions Architect Expert |
Microsoft 365 Administrator Expert |
 Terraform Associate |
 CCNA |
Skills and tools
Cloud and identity security, application security, infrastructure as code, continuous integration and continuous delivery security, detection engineering, security automation, and regulated environments.
Across these projects are implementation plans, architecture decisions, rejected alternatives, automated tests, security controls, failure records, and the checks added afterward.