Cloud Architect · Multi-Cloud · Kubernetes · Infrastructure Automation

Matthew Bowman

I'm a cloud architect — 15 years designing and running multi-cloud infrastructure across AWS, GCP, and Azure. The systems below are where I apply it: cloud-native platforms that automate security and operations.

Austin, TX · open to relocating · AWS · GCP · Azure · Kubernetes · Terraform · 15+ years

About

I'm a cloud architect with 15+ years across enterprise IT, multi-cloud architecture, and security operations. My day-to-day is designing and running production infrastructure across AWS, GCP, and Azure — infrastructure-as-code, Kubernetes, monitoring, and keeping it defensible under load. The projects below are where I take that same cloud-native discipline into independent R&D.

Hands-on with EDR-driven incident response (SentinelOne across 100+ environments), cloud security hardening, and high-tempo production incident work. Deep operator history in the gaming and media industry. Former U.S. federal Confidential clearance. I like problems where security, automation, and scale meet.

Focus
Cloud architecture · IaC · platform automation
Cloud
AWS · GCP · Azure · Kubernetes · Terraform
Security
SentinelOne EDR · IAM · PKI · log analysis
Code
Python · Bash · PowerShell · Go
Certs
CompTIA Security+ · Network+
Based
Austin, TX · open to relocating

Selected Work

Cloud-native systems I designed and built — the same architecture and automation discipline I bring to production infrastructure, taken into independent R&D. Concept-level; no client data or internal detail.

Cloud-Native Security Platform

Meridian

A containerized pipeline that chains asset discovery → risk analysis → automated verification, built to map how exposure accumulates across a cloud-scale attack surface.

Meridian operations console — discover → assess → verify → report
Meridian operations console — discover to assess to verify to report pipeline with live service status
See the assessment pipeline (assets redacted)
Assessment queue — asset hostnames and counts redacted
Meridian assessment pipeline — candidate results queued for human review, asset hostnames and counts redacted
Problem
Modern attack surfaces are too large to assess by hand, and defenders rarely see how an automated attacker actually prioritizes and moves.
Approach
A multi-stage, WAF-aware pipeline with CVE-first prioritization and breadth-then-depth heuristics that decide when to pivot vs. go deep — with evidence capture and structured reporting built in.
Impact
Turns days of manual assessment into continuous, prioritized signal, and doubles as a defender's lens on attacker tooling, tempo, and decision-making.
PythonDocker Compose · 30+ servicesorchestrationTerraform IaC · CI/CD deploycloud attack-surface automationLLM-assisted triage

Cloud Architecture · Serverless · FinOps

Serverless Cost Engineering

A deployable AWS reference stack — API Gateway (HTTP API) → Lambda on Graviton/arm64, all in Terraform — paired with the cost model that decides when serverless beats an always-on box, and when it doesn't.

Problem
"Just put it on Lambda" and "just run a server" are both defaults dressed up as decisions. The senior call isn't a preference — it's a breakeven you can defend with numbers, and most teams never run the math.
Approach
A minimal, least-privilege Terraform module — HTTP API, arm64 Lambda, IAM scoped to the API's execution ARN rather than a wildcard, and a Terraform-managed log group — that stands up and tears down with one command. Fronting it is a keyless, stdlib-only Python endpoint that packages with no build step. Beside the stack is the cost table: per-invocation Lambda + API Gateway charges measured against the monthly floor of a t3.micro / t4g.small always-on instance, every assumption stated (us-east-1, on-demand, and what the headline number omits — NAT, load balancer, cold-start init billing).
Impact
Turns the deploy decision from taste into arithmetic. For a light endpoint the serverless stack stays cheaper up to roughly 5M requests/month before an always-on instance wins — and switching the API Gateway type or the CPU architecture moves that line by multiples. The same table is the FinOps conversation a budget owner actually needs. Right-sizing, not dogma.
Terraform / IaCAWS Lambda · Graviton/arm64API Gateway (HTTP API)serverlessFinOps · cost modelingleast-privilege IAM

Platform Security · Cryptographic Provenance

Seal

Cryptographic provenance for AI-agent prompts — replacing brittle "injection detection" with signatures that fail closed, defined as a language-agnostic protocol with native implementations in Python, Rust, Go, and TypeScript.

Problem
Prompt-injection defenses based on reading language are guesswork; an attacker only has to phrase it differently.
Approach
Every prompt carries an Ed25519-signed Verified Prompt Envelope proving who authorized it, its scope, and that it wasn't tampered with. Turns an NLP problem into key management. The VPE is defined by its wire format and signature scheme rather than any one runtime, so the same authorization mints and verifies natively in Python, Rust, Go, and TypeScript.
Impact
A defense-in-depth primitive for agent systems that rejects unauthorized instructions by construction, not by vibes. Multi-language ports mean the protocol integrates at any layer of the stack.
PythonEd25519HMAC-SHA256protocol designRustGoTypeScript

Infrastructure Visualization · Network Observability

DECK

A 3D cosmos you fly through where the visualization is the scan — point it at a domain and that domain's full internet footprint reconstructs live, in real time, from passive OSINT.

Live scan of github.com — autonomous systems (suns), subdomains, IPs and prefixes as they resolve
DECK rendering a live 3D scan of github.com's internet footprint — labeled autonomous-system suns (GitHub, Cloudflare, Microsoft, Amazon), subdomain and IP clusters, and a live HUD of node counts and per-tier scan latencies
Problem
Network-mapping output is a flat text dump, and the public internet maps are frozen archives that each render one layer of the whole internet — neither gives you a live, navigable view of a single domain's complete footprint, or of the shape and timing of its attack surface.
Approach
An async, latency-tiered OSINT engine streams every probe result the millisecond it returns over a WebSocket to a 3D force-graph: domains, subdomains, IPs, prefixes and autonomous systems render as stars, planets, moons and suns, with BGP and DNS relationships drawn as gravitational lanes. Everything is keyless, and passive by default (DNS, Certificate Transparency, BGP whois, local GeoIP), and each node ignites the instant it arrives — so probe latency becomes the choreography rather than a loading bar. A 'home base' mode turns the same engine inward, mapping your own host outward in concentric shells and flagging live egress that falls outside your normal network neighborhood.
Impact
Turns recon from a static list into a live, explorable map where an attack surface's topology and timing are legible at a glance — and, pointed inward, into a defensive instrument that surfaces anomalous egress by construction.
PythonasyncioWebSocketThree.js · 3d-force-graphpassive OSINTBGP · Certificate Transparency

Streaming Detection Pipeline · Asset Monitoring

Sentinel Engine

Certificate-Transparency monitoring that surfaces new and anomalous infrastructure from internet-scale CT noise.

Problem
New subdomains, certs, and look-alike infrastructure appear constantly — phishing and shadow assets hide in the volume.
Approach
Continuously ingest public CT logs, extract and normalize domains, correlate against tracked roots, and surface only the new or anomalous as actionable intel.
Impact
Early warning on phishing infrastructure, subdomain sprawl, and shadow assets — attack-surface monitoring that runs unattended.
PythonCertificate Transparencystreaming correlationOSINT

Multi-Provider Evaluation Pipeline · AI Security

Assay

Multi-provider AI security evaluation framework — a systematic cross-model pipeline with a defense-agnostic runner supporting both local and cloud-hosted inference targets. 7 evaluation engines benchmark any defense middleware across the full discrimination battery on any model, regardless of how it is served.

Problem
All AI evaluation tools score a model's vulnerability, but none measure whether a defense middleware actually helps or by how much — you get a baseline and a prayer. And no tool provides a repeatable cross-model benchmark pipeline; every evaluation is a one-off.
Approach
Point at any model — Ollama-hosted locally or a cloud API target — and the same seven engines run the identical probe battery through a provider-agnostic abstraction layer that normalizes model interface, tokenization, and response format. Every evaluation engine (deterministic seed probes, NVIDIA garak probes, inline defense re-scoring, delta-driven reporting, expanded attack-vector coverage, plus the cross-model Phase M sweep) treats local and cloud targets identically: scoring, defense-lift measurement, and delta reporting are provider-independent by construction. The runner accepts a `--defenses` flag that applies any middleware uniformly across all probe engines; the defense registry is extensible by design — implementing one interface and declaring a map entry adds a new defender. LLM Guard (Protect AI) has been benchmarked as the first third-party defense alongside seal across all three target models (qwen3:8b, qwen2.5:14b, llama3.1:8b), with 126 total benchmark runs confirming the runner is defense-architecture-independent. Ships a premium HTML report and a multi-run results dashboard. The cross-model Phase M sweep across qwen2.5:14b and llama3.1:8b tests the defense against tool-chaining (STAC), hierarchical chain-of-thought (HCOT), and cross-modal attack types — structural attack classes that single-model Phase M could not discriminate. With benign-control discrimination metrics built into every battery, the framework measures TPR, FPR, and F1 alongside raw scores, distinguishing real blocking from blanket rejection. The pipeline is a reusable evaluation capability: any model, open- or closed-weight, local or cloud-hosted, can be systematically benchmarked across the full discrimination battery as a recurring discipline.
Impact
Turns 'is it secure?' from vibes to a letter grade, and 'does the defense help?' from guesswork to a measured percentage-point lift. The multi-provider architecture extends the same evaluation discipline from local models to cloud-hosted inference — enabling systematic comparison of model safety across providers on identical test batteries, with the same defense-lift measurement, the same discrimination metrics, and the same scoring framework. With the defense-agnostic runner, the benchmark question shifts from 'does seal work?' to 'how do the available defenses compare on a common instrument?' — any middleware can be measured against the same probe battery, on the same models (local or cloud), on the same terms. A new cloud API target integrates by implementing a single provider adapter; the abstraction layer normalizes interface differences so every engine runs unchanged. The cross-model Phase M sweep closes a critical blind spot: seal's injection defense, which registered zero discrimination against tool-chaining (STAC) and chain-of-thought attacks in single-model evaluation, achieves measured discrimination across multiple model architectures — 80.0 for STAC and HCOT, 60.0 for cross-modal — with zero false positives on the first cross-model verification, and these measurements now extend to cloud-hosted model targets as the same tape is run against any provider. The pipeline is a reusable evaluation capability: any model, open- or closed-weight, local or cloud-hosted, can be systematically benchmarked across the full discrimination battery as a recurring discipline.
PythonOllamagarakjailbreak evaluationdefense deltadeterministic scoringcross-model benchmarkdefense-agnosticmulti-provider evaluation

Automated Decision Pipeline · Risk Engineering

Midas

An autonomous research-to-decision engine that reads primary-source filings, forms structured theses, and routes every candidate through hard risk gates before anything acts — designed to survive being wrong, not merely to be right.

Midas operations dashboard — demo data
Midas operations dashboard — engine health, risk gates, open positions, and learning loop (demo data)
Problem
Automated decision systems optimize for being right and forget to optimize for surviving being wrong — a single bad sizing call ends the game.
Approach
A research-to-decision pipeline behind a layered risk gate, paper-trade execution, and a live operations dashboard. Most candidates are rejected by design; the system acts only when conviction and risk both clear.
Impact
Capital-preservation-first automation: it does nothing unless conviction and risk both clear — 'no decision' is the default, not a failure.
Pythonresearch-to-decision pipelinerisk-gate engineFastAPI ops dashboardpaper-trade execution

Mechanism Design · Protocol Security

Grommet

A boundary investigation of extraction-resistant sequencing — adversarial mechanism design proving that content-blind safety mechanisms cannot simultaneously bound attacker extraction and pass legitimate throughput under market stress.

Problem
Every permissionless blockchain suffers MEV/front-running. Proposed defenses claim extraction resistance, but none are systematically tested under adversarial stress. The space has no framework for auditing a mechanism's boundary conditions before deployment.
Approach
Rigorous iterated adversarial mechanism design: propose a hypothesis, simulate it (Python stdlib-only, deterministic and reproducible), subject it to adversarial review, then falsify or refine it. The output is a set of formal impossibility results, a catalog of dead ends, an audit checklist for any extraction-resistance claim, and an honest shippable spec built on existing batch-auction and threshold-encryption protocols.
Impact
The constraint framework is the product — a general design methodology for any protocol claiming extraction-resistant sequencing. Turns 'is it MEV-resistant?' from marketing copy into a falsifiable audit. A monetary-base extension applies the same safety principle as a minting rule for an engine-backed currency, where the impossibility does not bind.
Python (stdlib-only sims)MEV researchadversarial mechanism designformal impossibility proofprotocol security audit

News

2026-07-15

New project — Serverless Cost Engineering: the Terraform stack and the breakeven math behind 'Lambda or a server?'

Cloud architecture is full of defaults presented as decisions — 'put it on Lambda,' 'just run a server' — made on taste rather than arithmetic. This project makes the arithmetic first-class. It ships a minimal, least-privilege Terraform stack (API Gateway HTTP API → Lambda on Graviton/arm64, a Terraform-managed log group, and an IAM invoke permission scoped to the API's execution ARN rather than a wildcard) that stands up and tears down with a single command. Fronting it is a keyless, stdlib-only Python endpoint, deliberately dependency-light so the whole thing packages without a build step. The point isn't the endpoint — it's the cost model beside it: per-invocation Lambda plus API Gateway charges measured against the monthly floor of an always-on t3.micro or t4g.small, with every assumption stated (us-east-1, on-demand, and the costs the headline number leaves out — NAT, load balancer, cold-start init billing). For a light endpoint the serverless path stays cheaper up to roughly five million requests a month before an always-on instance wins; switching the API Gateway type or the CPU architecture moves that line by multiples. The deliverable is the decision procedure, not a preference: right-sizing you can defend to an engineer and to a budget owner in the same table.

2026-07-12

Assay Phase V defines the cross-provider cloud benchmark protocol — a methodology to run the full evaluation battery against any model, local or cloud-hosted, on the same tape

The multi-provider architecture (Phase U) gave Assay the ability to target cloud inference endpoints alongside local models. Phase V closes the gap between capability and execution: it formalizes the protocol for running the identical seven-engine benchmark battery against OpenAI's gpt-4o-mini and Anthropic's claude-sonnet-4 — the two industry baselines every AI security evaluation cites. The protocol specifies engine compatibility per target type (seed, modern, harmbench, hcot, stac, and crossmodal all run unchanged against cloud endpoints; garak and crescendo require provider-agnostic refactoring documented for a follow-up phase), defense coverage (baseline + seal-epd-llm across the board, with seal-stac as a third arm for tool-chaining attacks), and the post-run dashboard and gh-pages publication workflow. API cost is modeled at ~$5 for the full 32-run sweep across both providers; rate-limit profiles identify Anthropic's TPM ceiling as the operational bottleneck (addressed by built-in exponential backoff). The proposal treats the credential gate — missing provider API keys — as the sole blocking dependency rather than an architectural limitation, meaning the methodology itself is provider-complete: point at any inference endpoint with a valid key and the same evaluation discipline applies. Phase V is the final step that turns a multi-provider architecture into a multi-provider published benchmark.

2026-07-07

Assay cross-model Phase M sweep confirms seal defense can discriminate tool-chaining and chain-of-thought attacks — attack classes that read as background noise in single-model evaluation

The evaluation framework's Phase M attack battery — tool-chaining (STAC), hierarchical chain-of-thought (HCOT), and cross-modal injection — was re-evaluated across multiple model architectures with seal-epd-llm inline, and the numbers tell a different story from the single-model read. Where Phase M registered zero discrimination (the defense could not distinguish tool-chaining attacks from benign tool calls), the cross-model sweep finds measurable discrimination across all three attack classes: 80.0 for STAC and HCOT, 60.0 for cross-modal, each with zero false positives (FPR=0%). The result is not that seal-epd-llm learned to see something it could not see before — it is that coverage is architecture-dependent: an attack class that looks like noise on one model reveals structure under the defense on another. The evaluation framework now treats this as a first-class dimension: a risk-gated defense evaluation that sweeps not only across models but across attack-structural classes, so a coverage gap on one architecture does not masquerade as a fundamental limitation of the defense approach.

Archive · 9 earlier updates

2026-07-02

Assay benchmark engine goes defense-agnostic — LLM Guard benchmarked as first third-party defense alongside seal

Assay's benchmark runner now treats defenses as a pluggable dimension rather than a hardcoded pairing. The engine accepts a `--defenses` flag that applies any middleware uniformly across all probe engines, and the defense registry is extensible by design — adding a new defender means implementing one interface and declaring it in the map. LLM Guard (Protect AI) has been benchmarked as the first third-party defense alongside seal across all three target models (qwen3:8b, qwen2.5:14b, llama3.1:8b), producing cross-model LLM Guard coverage spanning 126 total benchmark runs. The runner is no longer tied to any single defense ecosystem; any middleware can now be measured against the same probe battery, on the same models, on the same terms, so the question shifts from 'does seal work?' to 'how do the available defenses compare on a common instrument.'

2026-06-30

Assay ships cross-model benchmark pipeline — 7 engines, 3 model architectures, published comparative benchmarks

Assay's evaluation pipeline is no longer a one-off instrument. All seven engines now run end-to-end as a systematic cross-model benchmark that has been validated across three distinct model architectures (qwen3:8b, qwen2.5:14b, llama3.1:8b) with published comparative results. The pipeline is a reusable evaluation capability: any model, open- or closed-weight, can be benchmarked across the full discrimination battery as a recurring discipline rather than a custom effort — making cross-model AI security evaluation routine. The next horizon (Phase I) extends the runner to be defense-agnostic, so any middleware can be benchmarked, not just seal, with LLM Guard as the first third-party defense candidate.

2026-06-27

Assay verifies seal-epd-llm defense is model-independent — cross-model validation confirms 93.3% injection-blocking across architectures

An independent cross-model validation of seal-epd-llm injection defenses, run via Assay on qwen2.5:14b, reproduced the identical 93.3% injection-blocking rate measured on the original target model — with the same three bypasses (deepinception, past-tense, crescendo-fictional-frame) in both cases. The result is the first published confirmation that seal-epd-llm's effectiveness is model-independent: the defense targets probe-level injection patterns, not model-level quirks, so evaluation results transfer across architectures and the technique can be trusted as a property of the defense itself. Phase G extends the benchmark to three or more models with full harmbench replication, establishing a publishable cross-model AI security benchmark.

2026-06-21

New project — DECK: when the visualization is the scan

DECK (Digital Echo Chamber Kaleidoscope) is a new R&D project — a 3D cosmos you fly through where reconnaissance renders at the speed information arrives. Point it at a domain and that target's full vertical footprint (domain to subdomain to IP to prefix to ASN, plus nameservers and mail) materializes live as a starfield, each node igniting the millisecond its passive-OSINT probe returns. The central idea is collapsing the gap between tool and output: there is no scan-then-draw step, so probe latency itself becomes the choreography — fast data fills the space first, slow data drifts in after. It is a different axis of internet cartography from the familiar maps (Opte, Shodan, crt.sh), which each render one frozen layer of the entire internet; DECK reconstructs a single target's complete footprint, live, on demand, with zero API keys. The metaphor carries the legibility: autonomous systems become suns, prefixes planets, hosts moons, and BGP links gravitational lanes, so abstract infrastructure turns into something you navigate by eye. A 'home base' mode turns the same engine inward as a defensive instrument — it maps your own machine outward in concentric shells and treats your normal BGP neighborhood as a still-water baseline, so any live connection leaving for somewhere outside that ring reads as a wave hitting a buoy: anomalous by construction. The lineage is Gibson's Neuromancer, where the deck is the thing you jack into to see cyberspace as navigable space.

2026-06-19

Seal's provenance protocol goes language-agnostic

The Verified Prompt Envelope — Seal's Ed25519-signed authorization layer — is no longer a Python-only idea. The envelope is defined by its wire format and signature scheme rather than any one runtime, so the central claim becomes concrete: prompt provenance is a protocol, not a library feature. Native implementations now exist in Rust, Go, and TypeScript alongside Python, which means an agent written in any of them can mint, carry, and verify the same authorization. The trust boundary follows the data across every tier of a heterogeneous stack instead of stopping at whatever language the defense happened to be born in. Provenance that only works in one runtime isn't a security primitive; provenance that survives the language boundary is.

2026-06-17

Midas: designing a decision engine to survive being wrong

Most automated decision systems are built to be right. Midas is built to survive being wrong — because in capital allocation a single oversized mistake ends the game, while being right is merely pleasant. The architecture encodes that asymmetry directly: candidate theses, formed by reading primary-source filings, must clear a layered gauntlet of independent risk gates before anything acts, and 'no decision' is the default outcome rather than a failure mode. The design thesis is that the gate layer — not the prediction — is the product: a system that does nothing unless conviction and bounded downside both clear is the only kind worth letting near real capital.

2026-06-17

Grommet concludes — three impossibility results for extraction-resistant sequencing

Grommet is an adversarial mechanism-design investigation into extraction-resistant transaction sequencing (MEV). Its terminal result is a formal impossibility: a content-blind safety mechanism cannot simultaneously bound attacker extraction and pass legitimate throughput under market stress — the two goals trade off hard. The deliverable is the constraint framework itself: it turns 'is it MEV-resistant?' from marketing copy into a falsifiable question, and ships an audit checklist any protocol making that claim should have to answer. The same safety principle has a constructive flip side — a minting rule for an engine-backed currency, the one regime where the impossibility does not bind.

2026-06-10

Seal grows to a three-axis trust layer, with Assay as the evaluator

Seal now coordinates all three agent-security axes — prompt provenance (Ed25519-signed authorization), injection detection (EPD linguistic boundary enforcement), and signed memory-trust — into a single unified defense plane. Each axis is independently effective, but their power is architectural: injection cannot rewrite provenance, memory-trust cannot be forged without the signing key, and no single-axis failure compromises the others. The three axes function as a coordinated defense plane, not three separate tools bolted together. Assay, the paired evaluator, scores a target across all three and measures the lift the defense actually adds.

2026-05-30

Seal: cryptographic provenance for agent prompts

Shipped the Verified Prompt Envelope — Ed25519-signed authorization that lets an agent reject unauthorized instructions by construction, turning prompt-injection defense from guesswork into key management.