Douglass A. Brown

Cybersecurity · Security Policies Capstone · 2026

enVisiAIn — AI Security & Governance

A complete security program for a company that doesn't exist yet — and the kind that soon will. Policy, risk, compliance, and DevSecOps for an AI health-technology startup whose software runs on people's faces.

enVisiAIn Security Awareness Training Module title slide — 'Protecting patient trust in AI-augmented vision care'

Overview

enVisiAIn is a fictional near-future (2030) health-technology startup I invented to make a security problem real: AI-augmented smart glasses, a companion app, and a cloud clinical dashboard, all built for blind and low-vision users. The product processes live video, retinal imaging, biometrics, GPS, and medical records — and feeds real-time AI navigation guidance to people who depend on it to cross the street safely.

Across a semester I built the company's entire security program: the governing policies, a formal risk assessment, a HIPAA and GDPR compliance plan, a secure code review, and a staff security-awareness training module. This capstone tied them together under one organizing principle — DevSecOps.

The Core Argument

For a company like enVisiAIn, security isn't a best practice — it's an ethical obligation. A compromised firmware update pushed to someone's smart glasses could cause them to misread a crosswalk signal. A poisoned AI model retrained on unvalidated data could produce navigation guidance that is systematically wrong. The stakes aren't leaked credit-card numbers; they're physical-safety outcomes for people already navigating a world not designed for them.

So the framework treats security as shifted left — built into every phase of the software lifecycle rather than bolted on at the end — and turns governance documents into pipeline enforcement instead of files in a shared drive:

  • Policy → pipeline: the Acceptable Use Policy becomes data-lineage gates and short-lived credentials (HashiCorp Vault) rather than written rules
  • Risk → pull request: threat modeling (OWASP Threat Dragon) attached to any change that alters the attack surface
  • Compliance → code: HIPAA safeguards and GDPR data-minimization enforced by SAST rules that fail the build, not a checklist

The Hard Parts of This Specific Environment

enVisiAIn acceptable-use policy slide — Do and Do-not guidance with the standard 'minimum necessary access, maximum accountability'

Generic DevSecOps covers a lot of ground, but three components needed tailored controls: smart-glasses firmware (code-signed via HSM-stored keys, staged rollout with automated rollback so a blind user never lands on a bad build), the AI model retraining pipeline (data-poisoning checks, adversarial-robustness testing, signed and versioned model artifacts), and the clinical dashboard (DAST scans, insecure-direct-object-reference checks so one clinician can't reach another's patients, append-only tamper-evident audit logs for the HIPAA audit-control requirement).

Why This One Matters to Me

I build AI systems. This project was the discipline of learning to govern and secure them — to think like the person responsible when the model is wrong and someone gets hurt. It's the difference between shipping a feature and standing behind a system. That's a posture I want to carry into every build, not just a class assignment I finished.