← Back to projects
Project · Secure Cloud Infrastructure

WHISPER

A Generalizable Framework for Securely Querying Public Data

WHISPER is a team research project building a generalizable framework for securely querying public data sources. This case study describes my individual contribution — the ephemeral compute and identity layer — not the full system or other contributors' work.

RoleContributor · Cloud & Security Engineering StackAWS · Python · FastAPI ProgramAFRL HBCU/MI SRIP StatusResearch Prototype

Project overview

WHISPER's goal, as a team, is to let services query public data sources without embedding long-lived credentials in client-facing code or maintaining always-on infrastructure that expands the attack surface over time.

My role on the team was the ephemeral compute and identity layer underneath that goal: provisioning short-lived, scoped AWS compute on demand, and making sure it never held more access — or existed longer — than a given job required.

My Contribution

Ephemeral compute & identity layer

Six pieces of infrastructure I built and integrated for the query-execution path.

Ephemeral compute provisioning

Used EC2 Launch Templates to spin up short-lived compute instances scoped to a single query job, rather than relying on persistent, always-on servers.

Automated lifecycle management

Boto3-driven automation to launch, monitor, and tear down compute resources automatically once a job completed — no manual cleanup, no orphaned instances.

Role-based authentication

IAM roles scoped per job rather than static, shared credentials, so each compute instance only had the permissions its specific task required.

Removal of embedded credentials

Replaced hard-coded and embedded credentials in client-facing code with temporary, role-assumed credentials issued at runtime.

API request layer

A FastAPI service behind AWS API Gateway and Lambda, handling request routing and triggering ephemeral compute provisioning for incoming query jobs.

Secure distributed workloads

Coordinated compute across distributed, ephemeral instances while keeping access control consistent across the fleet.

Request-to-teardown flow

How a query job moves through the infrastructure I built, from incoming request to automatic cleanup.

Step 1Request received+
A client request hits AWS API Gateway, which routes it to a Lambda-backed FastAPI service.
Step 2Job authorized+
The service resolves a scoped IAM role for the job — no static credentials are issued or embedded anywhere in the request path.
Step 3Ephemeral compute provisioned+
A short-lived EC2 instance is launched from a pre-defined Launch Template, scoped to this job only.
Step 4Query executes+
The instance runs the query against the target public data source under its scoped role, with no broader account access.
Step 5Automatic teardown+
Boto3 automation monitors job completion and terminates the instance and its temporary credentials — nothing persists past the job.

Why this approach

Long-lived servers and long-lived credentials both accumulate risk over time — every day they exist is another day they can be misconfigured, leaked, or exploited. Building the compute layer to be ephemeral by default and identity to be scoped and temporary shrinks that window deliberately: infrastructure that exists only for the duration of a job, with access limited to exactly what that job needs.

AWS API Gateway AWS Lambda Amazon EC2 EC2 Launch Templates IAM Boto3 FastAPI

Publication

This work was presented as a research abstract and poster at the HBCU/MI Summer Research Program Symposium, Air Force Research Laboratory, August 2026, as a co-author and presenter. Full citation details are on the Publications page.