DEV Community: Koushik Deb

Proof of Breath: Your AI Agent Can't Run DROP TABLE Until You Breathe

Koushik Deb — Tue, 10 Nov 2026 17:12:57 +0000

This is a submission for the Presage SmartSpectra SDK Challenge

What I Built

Proof of Breath is an approval gate for dangerous commands.

AI coding agents are fast. Sometimes they are too fast. They have run commands like DROP TABLE or terraform destroy and wiped real data. The usual "Are you sure? [y/N]" prompt does not help much. We press "y" without thinking.

So I replaced the "y" with a breath.

Here is how it works:

Normal commands run as usual. Nothing changes.
When an agent tries something it cannot undo, the command is held.
A window opens with a breathing pattern. The pattern is new every time.
You follow it with your breath, in front of your webcam.
The Presage SmartSpectra SDK reads your breathing and your pulse.
If your breath follows the pattern and a live pulse is there, the command runs. If not, it stays blocked.

An agent cannot breathe for you. A photo cannot breathe. A recording of an old check will not match a new pattern. And you cannot follow a breathing pattern on autopilot. You have to pay attention for a few seconds.

To be clear: this checks that a live person is paying attention. It does not check who you are.

Demo

Live app: https://pob.koushikdeb.com

The login page is already filled in for judges. Just press Sign in. You get your own private sandbox. It can never approve a real command.

Things to try:

Accept the consent notice.
Open Live reading. Keep your face and upper chest in view. Press start. Your pulse shows up after about 12 seconds.
Press Run it through the gate. Pick Your camera and follow the circle with your breath.
Pick Simulated to see attacks fail: a photo, a replayed session, or someone who ignores the pacer.
Open Case study. It shows the SDK reading a real recorded person. You can test that trace against new patterns.

For the recording, I used the Easy demo setting. It still needs a live pulse and a rough follow of the pattern, but it turns off the stricter checks. The default settings are stricter.

Code

DevDaring / Proof_of_Breath

Proof of Breath

A physiological approval gate for destructive developer commands. Routine commands pass untouched. When an AI coding agent tries something it cannot undo, such as terraform destroy or DROP TABLE, the command is held and a window opens with a breathing pattern that is different every time. It runs only if a live person's breathing, measured from a webcam by the Presage SmartSpectra SDK, follows that pattern and a live pulse is present.

Live demo: https://pob.koushikdeb.com. The login page is filled in with jury details: press Sign in. You get a private sandbox that can never approve a real command. In it you can use your own webcam for a real Presage SDK reading, or the clearly labelled simulated sensor.

Case study. Open Case study for real SDK output from a recorded person (numbers only, no frames), challenged with fresh patterns by the real verifier…

View on GitHub

Repository: https://github.com/DevDaring/Proof_of_Breath

The README has the full setup steps. You need PostgreSQL, Python, Node and a Presage API key.

Stack:

Backend: FastAPI and PostgreSQL
Frontend: React
Sensor: @smartspectra/node-sdk, running in a camera relay on the server or in a desktop bridge on your own machine
Hooks: Claude Code, a git pre-push hook, and a small CLI (pob run -- <command>)

How It Responds to Human Signals

I use these live signals from the SDK:

Signal	What the app does with it
Breathing trace	Checks that your breath follows the pattern
Pulse rate and confidence	Checks that a live pulse is present
Arterial pressure trace	Research score only. It never decides
Validation status	Tells you if your face is out of view or the light is bad
Breathing rate	Shown to you. Never used to decide

What happens in real time:

A circle grows and shrinks. You breathe in as it grows and out as it shrinks.
Your own breathing curve is drawn live, right next to the target curve.
Your pulse appears on screen once the SDK is confident.
If you move out of frame, a hint tells you right away.
When the window ends, the server scores your breath. The browser only shows things. It never decides.

The checks:

Does your breath match the pattern?
Do your inhales and exhales line up with the circle?
Did you take the right number of breaths?
Was a live pulse there for most of the window?
Does your breath match this pattern better than 20 other random patterns? This stops replays.

A pass gives a one-time token. It works for 30 seconds, and only for that exact command. Every decision goes into a receipt chain that shows if anyone edits it.

How I integrated the SDK:

The browser sends camera frames to a small Node relay on the server. The relay feeds them to the SDK with useCustomInput and sendFrame. The SDK streams breathing, pulse and status back. The backend scores them.

Things I learned the hard way:

The SDK needs your chest in view. With only a face, you get no readings at all, not even pulse.
The frame rate matters. Below about 20 frames a second, the SDK stopped with a processing error. I now fill small gaps by repeating the last frame to keep the rate steady.
The frame size must not change. A size change in the middle of a capture crashed the SDK. Every frame is now cropped to a fixed 640x480.
Errors can be retried. If the SDK reports a temporary error, the relay restarts it quietly, up to two times.

There is also a desktop bridge. It runs the SDK on your own computer, so video never leaves your machine.

Prize Categories

Best Thoughtful Real-World Use

The need: AI agents now run real commands on real systems. One wrong command can delete a database. A yes/no prompt turns into a habit, and habits don't protect anyone.

Who it's for: developers who let AI agents work in their terminal, and teams who want a real pause before destructive actions.

How I made it usable:

It only steps in for dangerous commands. Your normal work is not slowed down.
A check takes a few seconds.
The rules that decide what is dangerous are plain, fixed patterns. No AI makes that call.
There is a fallback for people who can't do paced breathing or don't want to use a camera. You type the exact name of the target, like the database name, and wait 20 seconds. The receipt records that the fallback was used.
The circle, sound cues and on-screen hints guide you, so you don't need to read instructions.

To be honest about where it stands: I have not run formal trials with many people yet. The thresholds are a first guess and will need tuning.

Consent and Data Handling

Proof of Breath does not diagnose, treat or monitor anything, and makes no medical claims. It only checks presence and attention before a destructive command runs.

Consent. Before the camera starts for the first time, a screen explains what is measured, what is stored, and how to delete it. You press "I agree". The app saves the date and the version you agreed to. You can withdraw consent in Settings at any time.

Camera. The camera only runs during a check or a reading that you started. You can see when it is on. It stops when the window ends. Nothing runs in the background.

Video. Video is never saved. Not on the server, not anywhere.

Browser camera: frames go over an encrypted connection to the relay. Each frame is read in memory, given to the SDK, and thrown away.
Desktop bridge: video never leaves your computer.
Simulated mode: no camera at all.

What is stored. One receipt per decision. It has the time, the scores, the decision, and a hash of the command. The command text itself is only stored if you turn that on.

Deleting. Settings has "Export receipts" and "Delete all data". Judge sandboxes are deleted after 7 days without use. Database backups are kept for 14 days.

Sharing. Your data is never shared or sold.

SDK telemetry. The SDK can send a small summary per session. It never includes video, measurements or identity. I turned it off by default. You can turn it on in Settings.

AI services. No user data goes to any AI service by default. One optional feature can explain a blocked command in plain words using NanoGPT. It is off by default and needs its own opt-in. The voice cues (ElevenLabs) and images (NanoGPT) were made once, at build time.

Agent Session

I built this with Claude Code.

The session shows the part I found most interesting: tracking down why the SDK failed on a real webcam. It turned out to be the frame rate and the frame size, not the camera.

Claim Attention

Koushik Deb — Sat, 06 Jun 2026 18:04:58 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Claim-Attention is a real-time attention compass. It takes one webcam frame every two seconds, finds your face with MediaPipe, and places your attention as a moving dot on a five-point compass: present at the centre, with internal thought , external distraction , past memory and future planning pulling outward.

Two ideas sit underneath it. MCASE (Multi-Cue Attention State Estimation) reads eye-aspect ratio, gaze, head pose, blink rate and small expression cues, then scores the five states. TADV (Temporal Attention Drift Vector) treats the dot as a spring-damper particle, so the motion stays smooth instead of jittery.

The project began as a small experiment around a personal question: where does my mind actually go when I believe I am focused? It grew into something I wanted other people to try, which is why it now runs in the browser, on Windows and on mobile against one shared backend.

Demo

GitHub Repo

DevDaring / Claim-Attention

Claim-Attention

Real-time Attention Compass powered by the MCASE algorithm Built for the GCP Gemini 2.0 Hackathon.

📁 Folder Structure

Code/
├── cloud_functions/    # GCP Cloud Functions (Python) — backend
├── terraform/          # Infrastructure-as-Code (Terraform)
├── web_app/            # React web application (Vite)
├── windows_app/        # Python Windows desktop app (CustomTkinter)
├── mobile_app/         # Flutter mobile app (iOS + Android)
├── .env                # Your secrets (gitignored)
└── .env.example        # Template — copy to .env and fill in

🚀 Quick Start Order

Before running anything, copy .env.example → .env and fill in your GCP keys.

1. Deploy Backend (when ready)

cd Code/terraform
cp terraform.tfvars.example terraform.tfvars   # fill in project_id
terraform init
terraform apply                                 # creates GCS buckets + Functions

2. Run Web App (local dev)

cd Code/web_app
cp .env.example .env                            # add VITE_CLOUD_FUNCTION_URL
npm install
npm run dev                                     # → http://localhost:3000

3. Run Windows App

cd Code/windows_app
cp .env.example .env                            # add CLOUD_FUNCTION_URL

…

View on GitHub

Live Software Link

The Comeback Story

I had left this half-finished few months ago. The backend and the React web app ran on my machine, but everything else had drifted out of sync:

The Windows and Flutter clients were stale and would not run against the current backend.
Calibration ran forever — it never completed, so you could never start a session.
The "Hide Camera" toggle did nothing.
Nothing was deployed, so there was no link to share.
The code map describing the project was out of date.

For the Finish-Up-a-thon I closed each gap:

Replaced the old Gemini-Vision validation with a provider-agnostic LLM second opinion (DeepSeek and Gemini through OpenAI-compatible APIs).
Added FocusWell , a predictive layer that estimates drift before it happens — a drift-risk gauge, a time-to-drift estimate, flow-streak detection and a pre-emptive nudge — then ported the same engine into the Windows (Python) and mobile (Dart) clients so all three behave alike.
Fixed the calibration hang (a renamed camera method that threw inside the capture loop) and the hide-camera binding.
Rewrote the Windows camera handling as a single reader to remove a frame race.
Deployed the whole project to Google Cloud Run as one small, scale-to-zero service that serves both the API and the web UI, which keeps the running cost close to nothing.

It now has a public URL and a working demo path: calibrate, start a session, watch the compass move, and get nudged just before you drift.

My Experience with GitHub Copilot

I built the original version with GitHub Copilot, and I finished it with Copilot too.

The part where it earned its place was porting FocusWell across three languages. The maths had to stay identical between the JavaScript reference, the Python desktop port and the Dart mobile port — same weights, same thresholds, same prediction steps. Copilot held the structure steady as I moved function by function, which is exactly the kind of careful, repetitive translation that is easy to get subtly wrong by hand.

It also carried the unglamorous finishing work: tracing the calibration bug back to a renamed camera method, writing the multi-stage Dockerfile that builds the React app and serves it from Flask, and settling the Cloud Run flags so the service scales to zero.

What I took from the finish-up is simple. The last ten percent of a project is mostly small, fiddly corrections across many files, and that is where an assistant which holds context across the whole codebase actually saves time.

Technical Details

Frontend: React (Vite) web app, Flutter mobile, and a Python CustomTkinter desktop app. Each runs a 2-second capture loop with client-side TADV smoothing and the FocusWell overlay.
Backend: Python Flask on Google Cloud Run, exposing six REST endpoints: /capture, /history, /latest, /sessions, /calibrate, /cleanup.
Vision and scoring: MediaPipe Face Mesh (478 landmarks) feeds MCASE features (eye-aspect ratio, gaze, head pose, blink rate, expression cues), which score the five states; TADV applies spring-damper physics for smooth motion.
Prediction: the FocusWell engine (drift risk, time-to-drift, flow streak, predicted path) is ported across JavaScript, Python and Dart with identical maths.
LLM check: every tenth frame, numeric features (not the image) go to an OpenAI-compatible model (DeepSeek via NanoGPT, Gemini via linkapi) and blend 70/30 with the local score.
Storage: sessions and readings as CSV plus JPEG media on the container disk (LOCAL_DEV); no external database.
Deployment: one Cloud Run service serves both the API and the built web app via a multi-stage Dockerfile (Node build, Python serve), scaling to zero when idle.

Koushik Deb
@debk