Nigeria
Avicenna’s British curriculum, a childhood surrounded by computers, and the realities of unreliable infrastructure.
CLINTON NWANNEA curious mind.
A curious mind.
A wider world.
Technology should make life better.
That is where my story begins.
Start anywhere
Three ways into my world.
A first invention. A wider perspective.
A question you can put to the test.
Six chapters. One continuing question: who does this help?
01 / CuriosityWhat if everyday effort
What if everyday effort
could become useful energy?
13years old
Curiosity became a prototype.
Growing up around unreliable electricity in Nigeria, I explored whether pedaling a stationary bicycle could generate energy for later use. Eco Breakfast brought energy conversion and storage into a problem I experienced firsthand.
It gave direction to my curiosity: I wanted to understand technology well enough to make it useful to the people around me.
Follow the energy
Ready when you are.
Start with human effort.
Pedaling supplies mechanical energy. The bicycle provides a familiar way to explore turning everyday movement into useful electrical output.
Conceptual explanation, not a circuit schematic or a measured efficiency claim.
The full origin story
At thirteen, growing up in Nigeria, I began exploring whether the energy we expend in everyday activity could help address the electricity shortages around me. I designed and built Eco Breakfast ↗, a science-fair prototype that converted the mechanical energy of pedaling a stationary bicycle into electrical energy through a motor operating as a generator, with a battery storing the output for later use. The project brought together energy conversion and storage in response to a problem I experienced firsthand. I still cycle today, and that early project remains a personal connection between something I enjoy and my desire to make technology useful. I was beginning to connect that local problem with a larger question: how could reliable electricity become more widely available without deepening environmental harm? It gave direction to my curiosity: I wanted to understand technology well enough to make it useful to the people around me.
Different places.
Deeper questions.
My father sold computers. I wanted to know what was inside them. Growing up and studying across countries widened that curiosity into questions about opportunity, institutions, and the people technology is meant to serve.
United Kingdom
Summer visits throughout my childhood added another recurring perspective, and more questions about how people live and how things work.
Canada
Columbia International College, learning alongside students from around the world and growing more independent away from home.
United States
Business and cybersecurity at Georgia State, then security engineering and graduate study at Georgia Tech.
A wider world to learn from.
Columbia International College brought me into a community of students from around the world. Learning away from home made independence part of my education.
A milestone worth remembering.
My BBA in Computer Information Systems connected business judgment with a concentration in cybersecurity.
Education, independence, and the journey
My father sold computers, and I grew up taking them apart to understand how they worked. My education took me from Avicenna, a British-curriculum school in Nigeria, to Columbia International College in Canada, where I studied alongside people from around the world. Living away from my parents required independence, while learning across different environments broadened the questions I brought to technology. I also visited the United Kingdom every summer growing up, and have traveled to Dubai and Switzerland. Across these experiences, I kept asking questions about the places around me and how things worked. At Georgia State’s Robinson College of Business, I earned my BBA in Computer Information Systems with a cybersecurity concentration. That training gave me a foundation for examining technical decisions alongside organizational priorities and risk.
Security matters
because people depend
on the system.
4QGenda product lines
in my vulnerability-management scope
in my vulnerability-management scope
4,500+healthcare organizations served by QGenda
Company-wide scale ↗
Company-wide scale ↗
I work where technical controls, regulatory expectations, and operational decisions meet. My responsibility includes coordinating remediation, defining validation requirements, reviewing cloud permissions, and assessing exceptions against evidence.
Find the risk→Assign ownership→Validate the fix→Account for exceptions
An explanation of my approach, not a diagram of confidential company infrastructure.
Scope, standards, and the human stakes
At QGenda, whose software serves more than 4,500 healthcare organizations ↗, I own vulnerability management across four product lines within a healthcare technology security program informed by the HIPAA Security Rule and NIST guidance. I coordinate remediation priorities with engineering and SRE, define responsibilities and validation requirements, and assess exceptions against documented evidence. My AWS Security Hub work includes findings mapped to the CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. I also review Terraform execution plans and IAM permissions, and built a reusable query supporting 30 access comparisons across 12 applications. These responsibilities place me where regulatory expectations, technical controls, and operational decisions meet.
The stakes become concrete when I consider what those systems support: workforce scheduling, credentialing, and on-call coordination. If information about clinical coverage becomes unavailable or unreliable, the resulting disruption can reach the people coordinating care. Protecting confidentiality, integrity, and availability therefore carries a responsibility to the healthcare teams who depend on these systems. My contribution is to help reduce security risks to that operational foundation. This is why I want to study cybersecurity policy more deeply: to understand how institutions translate responsibility for dependable care into enforceable requirements, justified risk decisions, and accountable practice.
A finding’s status is not enough. I look for the source evidence, the responsible owner, and a defensible reason for the decision.
Terraform plans and IAM permissions need to be understood in terms of the authority they grant and the systems they affect.
Beyond the screenA little more of
A little more of
the person behind the work.
Curiosity takes me into new places, new conversations, and communities of people building things.
04 / My Georgia Tech chapterA Yellow Jacket.
A Yellow Jacket.
A wider view of the world.
Capability needs accountability.
At Georgia Tech, studying Global Development has deepened how I think about security: institutional capacity, authority, legitimacy, and the consequences of decisions.
How development studies inform my engineering
At Georgia Tech, I have earned a 4.00 graduate GPA, with A grades in Introduction to Global Development and Introduction to GIS. Having lived in Port Harcourt amid insecurity, I came to development studies with a personal interest in how institutions protect people and where that protection breaks down. My current Development and Security course gives me a framework for examining that question through institutional capacity, authority, and legitimacy. A police department may gain more officers and better equipment, but those resources do not make people safer if the resulting power is used to intimidate them. I see a related problem in cybersecurity: giving an administrator or an AI agent access to more systems increases what it can do, but we must still determine which actions are justified, how its activity is audited, and who can intervene when something goes wrong. In both settings, greater capability needs accountable oversight. I want to carry this institutional perspective into the study of cybersecurity policy, alongside my engineering experience.
The connection
Giving an institution or an AI agent more power changes what it can do. Governance asks what it should do, who is accountable, and who can intervene.
How do we make
authority accountable?
As AI systems gain the ability to act, I want their authority to remain limited, auditable, and revocable. My independent projects explore how that principle becomes an engineering practice.
Interactive experimentHow much power
Open the permission playground ↗Interactive caseWould you trust
Open the evidence desk ↗
How much power
would you give an AI?
Open the permission playground ↗Interactive caseWould you trust
this security alert?
Open the evidence desk ↗Public proof of concept
AI Agent Infrastructure Security
Scoped cloud permissions, Kubernetes RBAC, and emergency containment. Offline validation is documented; live cloud enforcement still needs verification.
Explore the repository ↗Public security tool
Security Findings Workbench
A reproducible way to reason about findings, evidence, and exceptions using synthetic data. Designed to make security decisions inspectable.
Inspect the work ↗FindingEvidenceDecision
Public infrastructure tool
Terraform Change Review
Exploring how infrastructure changes can be reviewed systematically before they become operational changes.
Explore the repository ↗AI, institutional responsibility, and my research direction
That concern also informs my writing on Project Glasswing ↗. In discussing AI-assisted security, I returned to a practical constraint: discovering weaknesses is useful only when organizations understand their dependencies and have the capacity and incentives to act. I want to investigate how policy can make that response more accountable and effective.
In my public AI Agent Infrastructure Security project ↗, I explore delegated authority through scoped cloud permissions, Kubernetes role-based access control (RBAC), and emergency containment. I have documented the proof of concept’s offline tests and the live verification still required. As infrastructure changes become programmable and AI agents gain the ability to act on systems, I am interested in how oversight can keep pace with execution. Policy as code can translate security requirements into automated checks, but organizations must still decide who defines those rules, who can override them, and how exceptions are reviewed. I want to investigate what evidence should be required before delegating authority to an AI agent, and how that authority can remain limited, auditable, and revocable.
I am interested in the intersection of technical identity and institutional accountability. One question I want to pursue is how an organization should connect an agent’s permissions to a clearly accountable human decision-maker.
Make the opportunity
count.
Getting to Georgia Tech required sustained work and sacrifices from my family. Being here has expanded what I believe I can contribute.
My goal is to help organizations and communities, including those in Nigeria, adopt technology they can depend on.
Where I want to take this work
Georgia Tech has long been my dream school. Getting here required sustained work and sacrifices from my family. Being here has expanded what I believe I can contribute, and I want to make that opportunity count. My goal is to become a security engineer with the judgment to help organizations and communities, including those in Nigeria, adopt technology they can depend on.
I want to bring practical engineering, business judgment, and an institutional perspective to the study of cybersecurity policy. The next stage of my education should strengthen how I turn those perspectives into rigorous, useful work.
Let’s work on
what people depend on.
For engineering teams, my focus is cloud security, vulnerability management, IAM, and automation. For research collaborators, my question is how increasingly capable systems can remain accountable.
Inside my engineeringA reassuring label.
A reassuring label.
A different reality.
An alert has been set aside. The record was updated yesterday. Is it safe to move on?
Try the decision behind my Security Findings Workbench. Open the evidence, then make your call.
The first impressionThis alert
Set aside SUPPRESSED
This alert
looks handled.
Set aside SUPPRESSEDThe system reports a recent update. But a status label cannot tell the whole story.
Notice→Inspect→Decide
Look beneath the label
Updated October 7. Last observed September 1.
Updating a record is different from checking the underlying system. The observation is 37 days old, beyond this demonstration’s 14-day freshness threshold.
The exception has expired.
Permission to postpone action needs an owner, a reason, a reference, and an expiry date. This record no longer has an active exception.
Bring it back for urgent review.
The tool flags the expired exception and stale observation. This high-severity finding is also overdue under the sample policy, so it returns to urgent review. The source identity stays attached to the decision.
What would you do?
Your decision will appear here.
From idea to inspectable code
Why I built it this way.
The workbench keeps source identities, keeps the last observation separate from the latest record update, and returns expired exceptions to review. Those choices make the reasoning reproducible.
Open the technical evidence +
This interaction explains a fixed output from the public Python project. It does not execute the workbench in your browser.
- Exact finding identity
- ProductArn + Id
- Freshness field
- LastObservedAt
- Demonstration output
- urgent_review
- Input boundary
- Synthetic records only
Independent portfolio demonstration. No employer data, live cloud access, or verified remediation. The sample prioritization and freshness thresholds are illustrative.