Brandon Anthony

Security GRC · Third-party risk · Maryland

Brandon Anthony

At a glance

  • 8+ years in security GRC and third-party risk
  • ISO/IEC 27001:2022 Lead Auditor Certified · Mastermind
  • M.S., Cyber Security Technology University of Maryland Global Campus
  • Per Scholas Curriculum Advisors Network Per Scholas · 2026
  • Founder of Otti a pediatric occupational therapy EMR, in daily use by a live practice
  • Vanta · SecurityScorecard · S-RM · Coalfire Federal where I’ve worked since 2018

Page last reviewed .

Case studies

Otti, the EMR I founded, and three of the controls behind it: what each one had to stop, how it is proven, and what is still open.

The product

Otti

  • In production since October 2026

What it is

Otti is an EMR and family portal for pediatric occupational therapy practices, in daily use by a live practice.

My role

I’m Otti’s founder and product owner. Otti was built by AI coding agents under my direction: I led development with Claude Code, directing agents across build, code review and security testing, and took it from idea to production in about three months.

How it’s governed

Otti runs under a compliance program designed around HIPAA.

  • Risk register. I maintain a HIPAA-based risk register for the platform.
  • Trust boundaries. Set between practices, families and clinical records, and proven by attack tests that try to cross them and must be refused.
  • Proof for every security fix. Required every security fix to be proven by a test that fails if the bug is put back, with attack tests on every privileged server route.
  • Release controls. Designed a staging-first CI/CD pipeline that blocks deploys on failed tests or dependency audits.
  • AI governance. I maintain an AI touchpoint register and rules based on Microsoft HAX (guidelines for human-AI interaction) and CSA AARM (Autonomous Action Runtime Management). Product AI runs a fixed set of tasks on a HIPAA-covered model; a figure the clinician typed always wins over a suggestion, and every task call is logged without its content.

Built on React, Tailwind CSS, Firebase, Google Cloud, Vertex AI, GitHub and Google Workspace.

No patient data appears on this page.

Visit ottihealth.com Read Otti’s security page

AI governance

Guardrails for an AI inside a child’s chart

The controls around the AI inside Otti, a children’s therapy record in use at a live practice.

Otti’s AI drafts session notes and reads goal scores out of them. It runs a fixed set of tasks on a HIPAA-covered model, a figure the clinician typed always wins over its suggestion, and every task call is logged without its content.

Read the full case studyHide the full case study: Guardrails for an AI inside a child’s chart

The problem

A stolen login could turn the AI into a free general-purpose model billed to the practice. The model could score a goal the session never touched, straight into the chart. And clinical text sent to the model could be copied into logs.

The constraint

There are two threats. Against a stolen session, a check in the browser protects nothing, because whoever holds the session controls the browser, so those controls live on the server and fail closed. Against a wrong answer, review alone is not enough: after a full day of visits, a plausible number gets accepted. So the answer is checked before the clinician sees it.

What I did

I set the rules, directed the AI coding agents that wrote Otti, and verified the results.

  • Task names, not prompts. The server accepts a task from a fixed list and writes the prompt itself.
  • Positions, not IDs. The model gets goals as a closed, numbered list and answers with positions in it. Anything outside the list is dropped, and so is any row whose quote is not in the note.
  • Kept by hand. A goal reading is saved only when the clinician keeps it. A figure already typed wins, and a kept reading is marked as AI-sourced.
  • Bounded and logged. Calls are rate-limited per minute, for runaway loops, and per hour, for slow abuse. Every task call is logged by size, outcome, model and region, never its content.
  • A covered model. Production runs on Vertex AI, which is on Google’s HIPAA covered-products list. Google’s non-covered API is refused on the practice’s own projects, and a preview model fails the tests.
  • Governance. A register lists every AI touchpoint, what it reads, where its output lands and whether a person checks it first, and a test fails if a task has no row. Rules based on Microsoft’s HAX guidelines reject learning from users, because a signed note is a legal record.
simplifiedrequest  { task: "scoreGoals", goals: ["Cut a 6-inch line", "Fasten a zipper"], note }answer   { goal: 2, evidence: "zipped coat with min assist" }dropped  if goal is not 1 or 2, or the evidence is not in the note

How it’s proven

Mutation testing exposed a blind spot: a task that passed the caller’s text straight through still passed every behavioural test, because those tests only checked tasks they knew. Two tests now read the source. One scans for a caller’s field passed through as the prompt, and the other fails if the code and the task list disagree. Re-run on the live release, that mutation still passes the other 92 tests in its file and fails both. Removing the position check, the quote check or the rule that a typed figure wins also turns a test red, as does copying the prompt or the reply into the audit record.

What’s still open

Omissions. The checks catch a reading the note does not support. They cannot catch a goal the note did address that the model left out. That goal simply gets no suggestion, and the clinician scores it by hand, as without the AI.

Access control

Proving isolation instead of asserting it

A rule on paper shows design. Evidence it held through every code change shows it operating.

Read the full case studyHide the full case study: Proving isolation instead of asserting it

The problem

Otti holds real children’s records for a live practice, and it is built so every practice and every family shares one database. One wrong rule could show a practice another’s charts, or a parent the clinician’s notes, while looking correct.

The constraint

Hiding data in the app isn’t a control: the browser talks to the database directly, and anyone can modify the app. And a test at launch proves nothing about next month’s edit.

What I did

I set the requirements and the standards, directed the AI coding agents that built Otti, and verified the results.

  • The practice is stamped server-side into each staff account; the browser never chooses it. The staff-invite endpoint refuses a request that names a practice rather than comparing it, so there is no comparison for a later feature to quietly relax.
  • The data layer enforces it. The database and file store check every read and write the app makes to a chart against that stamp, so a modified app meets the same wall.
  • Families are outsiders. A parent’s account carries no practice, so every clinical rule refuses it, even for their own child. What parents read from the database is a physically separate copy the practice publishes to them, never a filtered view of the chart, and the database rejects any copy with a field outside a fixed list. Bills, which change daily, are the exception: server code reads them for the family’s own children only.
// simplifiedallow read, write: if signed_in                   && token.practice != ""                   && token.practice == practice_in_path

How it’s proven

The rules are the design. This is the operating evidence.

  • Attacks on every code change. Another practice’s staff, a family, an anonymous caller and look-alike tokens try cross-practice and cross-family reads and writes against the same rules that ship. One success fails the run.
  • Coverage is mechanical. A test fails if any rule granting access has no attack against it.
  • No vacuous passes. The rightful user reaches the same records, so a refusal proves the boundary, not a rule that refuses everyone.
  • Mutation testing. The standard for every fix: put the bug back and the test must go red. Across the codebase, that has caught tests that still passed with the bug in place.
  • Evidence. Each of those runs leaves a dated, commit-pinned record mapped to HIPAA access-control standards, and fails the build if a control suite is missing, empty or red.

What’s still open

  • Privileged server functions sit outside the database rules by design; there the code is the boundary, with its own attack tests.
  • Every rule is attacked; not every possible attack is written.
  • Mutation testing is a review standard, not an automated gate.
  • The tests prove the rules as written, in an emulator, not live configuration.

Operating effectiveness

The control that existed on paper

The size limits were in the code, and a passing test said they worked. In production, none of them ran.

Read the full case studyHide the full case study: The control that existed on paper

The problem

Each group of server routes declared the largest request it would accept, and an attack test confirmed an oversized one was refused. In production, a route sized for 8 KB took whatever it was sent, in full. Paired with a slow address check (since fixed), one such request could hold a server for its full timeout.

The constraint

The serverless platform parses each request body before the app sees it, so the app’s size checks found the work done and stepped aside. The test ran the app on a plain web server, where those checks do run: real evidence, about a different system.

Weeks earlier, the same platform behaviour had broken a payment callback’s signature check on staging. That was fixed, but the same cause was not traced to the size limits.

What I did

I set the rules, directed the AI coding agents that built Otti, and verified the results. A security review found the gap; the fix was live about a week later.

  • One guard, first in line. It refuses an oversized request before any route runs.
  • One source of truth. It reads each route group’s own limit list, the one its parser uses, so they cannot drift.
  • Measure what was read. It counts the body the platform actually read, not the size a request claims.
// simplifiedlimits = combine(each route group's own limit list)before any route runs:  size  = length of the body the platform actually read  limit = limits[longest matching path prefix] or a small default  if size > limit: refuse with 413 "too large"

How it’s proven

  • The test plays the platform. It loads the file a deploy runs and serves it as the platform does, body parsed first. Oversized requests must be refused; normal ones admitted.
  • A control on the control. A second test reads the server code and fails if a parser carries its own number, is mounted on a path the guard doesn’t know, or turns up too few parsers to prove anything. Within days, a feature built before the guard had its limit inline; the test rejects that, so the limit joined the list before shipping.
  • Mutation-tested. Removing the guard, ignoring what the platform read, or dropping a route group from the list each turns the suite red. The suite runs in the automated checks on pull requests.

What’s still open

  • The suite reproduces the platform; it does not probe the live service.
  • The coverage test matches a pattern; an unusually written parser could slip past.
  • Mutation testing is a review step, not an automated gate.

The lesson: a green test is not operating evidence. Test a control where it runs, and when one cause breaks a control, check the other controls that share that cause.

Overview

I’ve worked on third-party risk programs for large enterprise and government clients, led security and compliance implementations, and supported sales teams as a subject-matter expert. I use AI agents to automate GRC work.

Today I help GRC teams get their programs running in Vanta, and I’m the founder and product owner of Otti, an EMR and family portal for pediatric occupational therapy practices.

Scope

Frameworks
SOC 2, ISO 27001, NIST CSF, NIST 800-53, FedRAMP / RMF, CMMC, HIPAA
Third-party risk
Vendor security assessments, SOC 1 & 2 and SIG review, vendor interviews, issue tracking and remediation, continuous monitoring, security ratings, TPRM program design
AI and automation
Claude Code, Dust, MCP, Vertex AI, AI agents and LLM workflows for GRC, API automation
Client-facing
Enterprise implementation, CISO-level advisory, demos and PoCs, sales enablement, product feedback

Experience

An evidence log: each role, with what I did there.

  1. Post-Sales GRC Subject Matter Expert · Vanta

    January 2026 – Present

    • Help GRC teams get their security and compliance programs running in Vanta, from implementation to adoption.
    • Guide setup across Vanta’s frameworks (SOC 2, ISO 27001, HIPAA, NIST and more), and map integrations to controls.
    • Design third-party risk workflows, and guide setup of Vanta’s AI agent for security questionnaires.

  2. Founder & Product Owner · Otti

    July 2026 – Present

    • EMR and family portal for pediatric occupational therapy practices, in daily use by a live practice since October 2026.
    • Led development by directing AI coding agents with Claude Code across build, code review and security testing, from idea to production in about three months.
    • Established a compliance program designed around HIPAA, with a HIPAA-based risk register.

    Read the case studies

  3. Senior Consultant, Cyber Risk Solutions · SecurityScorecard

    January 2025 – January 2026

    • Built and implemented third-party risk programs for enterprise and government clients, fitting SecurityScorecard products into their intake, assessment and monitoring.
    • Led large third-party security reviews from intake to reporting, and aligned vendor assessments with NIST CSF, NIST 800-53, ISO 27001 and CMMC.
    • Served as the third-party risk subject-matter expert on prospect calls and in sales enablement.

  4. Senior Associate, Cyber Advisory · S-RM

    August 2022 – November 2024

    • Led third-party risk assessments: vendor interviews on site and remote, and review of SOC 1 and SOC 2 reports and SIG questionnaires.
    • Developed TPRM policies, procedures and frameworks aligned to each client’s risk appetite and regulatory requirements.
    • Led ISO 27001 readiness work (risk assessments, gap analyses, ISMS documentation) resulting in successful ISO 27001:2013 and 27001:2022 certifications.
    • Conducted NIST CSF assessments, evaluated private equity portfolio companies for M&A activity, and delivered on-site audit support to global investment and law firms.
    • Assessed client security posture for cyber insurance underwriting, advising a leading global insurance firm on prospective Fortune 500 clients.

  5. Cyber Risk Consultant · Coalfire Federal

    October 2018 – August 2022

    • Served as ISSO supporting FedRAMP authorization for cloud-based federal systems, managing security controls and RMF documentation (SSP, BIA, PIA, PTA, MOU, ISA).
    • Created the agency’s risk acceptance policy and procedures, and drafted risk acceptance memos and waivers for CISO and CTO approval.
    • Led a team of 3 handling all security education, training and awareness (SETA) tasks for the agency, and implemented its first automated training tracking and alerting system in ServiceNow.

Certifications and education

Certifications

  • Certified ISO/IEC 27001:2022 Lead Auditor · Mastermind
  • Supply Chain Defense Analyst · SecurityScorecard
  • Per Scholas Curriculum Advisors Network · Per Scholas · 2026

Education

  • M.S., Cyber Security Technology · University of Maryland Global Campus · 2021
  • B.S. · Monmouth University · 2017 · NCAA Division I Football

Contact

I’m based in Maryland. The best way to reach me is LinkedIn or email.

LinkedIn profile