Manish Gaud

— CASE STUDY / AI PRODUCT

A daily AI brief on your AWS account, with cross-signal root-cause traces.

Cloudbrief is the AWS observability product I built as founder — shipped under the Kashi Labs brand. It connects to a customer's AWS account read-only, runs every 24 hours, and writes a narrative brief: cost spikes caught early, root causes traced across cost / database / HTTP / Lambda signals, and incidents you would have missed flagged before they balloon.

Founder & lead architect · 2026–present · Live · Early release

View live demo →

— Section B

Context

Most AWS cost regressions and reliability incidents leave fingerprints across more than one signal — a spike in RDS read IOPS, a clustered HTTP 5xx, a Lambda concurrency wall — and most teams don’t notice until billing or pages catch up. Cost Explorer answers “what did we spend” after the fact; CloudWatch answers “is this metric breaching” without context; Cost Anomaly Detection flags an anomaly but rarely traces it to the change that caused it. The space between those tools is where a six-figure surprise lives.

Cloudbrief is a daily AI brief on your AWS account. It connects via a read-only IAM role (the policy template is published; under-five-minute customer onboarding), runs deterministic detectors across cost / RDS / HTTP / Lambda / S3 every 24 hours, and writes a narrative finding only when more than one signal points in the same direction. Claude synthesizes; the detectors decide what counts as a signal. Every finding cites the metric data point that triggered it — engineers can audit and disagree.

Built as the first product under the Kashi Labs brand, sharing infrastructure with Paperbrief. Same architectural patterns I deploy with clients, applied to a problem I wanted solved myself.

Claude is good at synthesis, not arithmetic. Detectors do the arithmetic; Claude writes the brief.

— Section C

My role

I’m the founder, sole architect, and lead engineer. I designed the IAM scoping, the per-tenant credential encryption, the detector contracts, the scheduled-analysis topology, and the deployment shape (single Lightsail box shared with Paperbrief, full IaC in OpenTofu). I used modern AI coding tools — Cursor, Claude — under my direction to accelerate implementation. The architecture decisions, the detector taxonomy, the rollout sequence: all mine. Every line that ships, I review and own.

— Section D

The hard parts

Five architectural decisions worth surfacing. Each one is the kind of choice people regret not making earlier — and several are the kind that, on a product handling customer cloud credentials, can’t be regretted at all.

D1

Customer AWS credentials are pgcrypto-encrypted at the column level

A SaaS that holds other companies’ AWS credentials is a credential aggregator with a target on its back. Application-level encryption (the backend wraps and unwraps in Python) means a single SSRF or memory-dump bug exposes plaintext. Disk-level encryption (the EBS volume is encrypted) means anyone with database access reads cleartext.

Cloudbrief stores the customer’s AWS access key and secret as bytea columns encrypted with pgcrypto symmetric encryption. The encryption key lives in AWS SSM SecureString and rotates independently of the application. A read-only SELECT against aws_accounts returns ciphertext; the only path to plaintext is through a database function the API uses with the runtime key. A leak of the database without the SSM key is useless; a leak of the SSM key without the database is useless. The dangerous path requires both.

D2

Onboarding is a read-only IAM role and a published policy template

The bar for a customer to try Cloudbrief is: paste an external ID, paste a role ARN, hit verify. The role policy is published — Cost Explorer read, CloudWatch metric/logs read, RDS Performance Insights read, Lambda read, S3 list/get-bucket-policy, IAM list (no write anywhere). Customers can review the policy line by line before they create the role. Verification runs sts:AssumeRole end-to-end and refuses to save the connection if a single permission is missing.

The pattern matters because it sets the trust ceiling honestly. Cloudbrief cannot modify anything in a customer’s account — not a tag, not an alarm, not a parameter. Operators sleep better knowing the product is structurally incapable of writing.

D3

Detectors do the arithmetic; Claude writes the brief

The temptation in an AI product is to hand the LLM the raw metrics and a prompt that ends “find anomalies.” That product silently hallucinates within a week — a percentage point off, a wrong service named, a confident sentence that contradicts the data. The downstream cost of a wrong finding is high (an engineer pages, a finance partner re-runs the math) so the bar for correctness is high.

Cloudbrief inverts the order. Deterministic Python detectors (cost-spike, RDS slow-query, HTTP error-budget, Lambda throttle, S3 unusual-egress) run against scoped metric pulls and emit candidate signals with explicit thresholds and citations. Only when two or more detectors agree on a window does Claude get called — and even then, Claude’s prompt includes the raw signal payloads and is told to summarize, not infer. Every emitted finding includes a metric trail; the user can click a number and land on the underlying datapoint. Hallucination has nowhere to hide.

D4

Single-box deploy, full IaC, $24/mo infra

An early-stage AI product that consumes Anthropic and OpenAI tokens is paying for the LLM. The infra around it should not also be expensive. Cloudbrief and Paperbrief share one Lightsail box in Mumbai (medium tier, 4 GB RAM, $24/mo), one PostgreSQL 16 instance, one nginx, one set of systemd units. Static frontends live on Cloudflare. The TLS path is Cloudflare Origin CA — 15-year certs, zero certbot rotation.

What makes the single-box shape safe is full Infrastructure-as-Code. OpenTofu manages the Lightsail instance, static IP, IAM users, S3 buckets, SES domains, SSM parameters, CloudWatch alarms, SNS topic, and the Cloudflare zones / DNS / Origin CA. Disaster recovery is tofu apply + an Ansible play + a Postgres restore from S3 — measured target is 30 minutes. The architecture refuses the false choice between “cheap and fragile” or “robust and expensive.”

D5

Multi-tenant org-scoping with an append-only access audit

Every detector run, every finding read, every credential rotation writes a row to an immutable access-audit table. The table has a trigger that rejects updates and deletes — once a row lands, it stays. The audit row carries the org_id, the user_id, the action, the resource accessed, and the request fingerprint. When a customer asks “who looked at our findings on Tuesday,” the answer is a SQL query, not a log-search through CloudWatch.

The same org_id is the primary tenant key on every domain table — accounts, findings, runs, settings. Row-level security policies on the PostgreSQL side make WHERE org_id = current_org() implicit; an endpoint that forgets to filter returns zero rows rather than another org’s. The dangerous path requires intent.

— Section E

Architecture

Cloudbrief ingest topology: customer AWS account → read-only IAM role → scoped metric APIs → deterministic detectors → Claude synthesis → findings store
Read-only IAM role → scoped metric pulls → deterministic detectors → Claude synthesis (only when two or more detectors agree) → findings store. Customer plaintext credentials live nowhere outside the pgcrypto-encrypted column.
Cloudbrief detector flow: APScheduler kicks per-org analysis every 24h; each detector emits signals with citations; the synthesis stage writes a narrative finding only when signals corroborate
APScheduler kicks per-org analysis every 24h. Each detector emits typed signals with thresholds and metric citations. Synthesis writes a narrative finding only when signals corroborate.

— Section F

Stack

Backend
FastAPI · Python 3.12 · PostgreSQL 16 (pgcrypto + native RLS) · APScheduler (per-org 24h cadence) · Anthropic Claude (synthesis only) · AWS SDK (read-only across Cost Explorer, CloudWatch, RDS Performance Insights, Lambda, S3, IAM)
Frontend
React · Next.js (static export) · TypeScript · Tailwind CSS
Infrastructure
AWS Lightsail Mumbai (4 GB box shared with Paperbrief) · Cloudflare (DNS, Origin CA 15y, edge cache) · AWS SSM SecureString (Anthropic key, pgcrypto key, OAuth secrets) · OpenTofu (full IaC: Lightsail, S3, SES, IAM, SSM, CloudWatch alarms, SNS) · Nightly pg_dump → S3 with 30-day retention

— Section G

What shipped

Live at cloudbrief.app under the Kashi Labs brand. The product runs end-to-end on production infrastructure and onboards real customers in early release.

  • — Read-only IAM role onboarding via published policy template; verification runs sts:AssumeRole end-to-end before saving.
  • — Customer AWS access keys stored as pgcrypto-encrypted bytea columns; key rotates independently of the application via AWS SSM.
  • — Deterministic detector library: cost-spike, RDS slow-query, HTTP error-budget, Lambda throttle, S3 unusual-egress. Each emits typed signals with thresholds and metric citations.
  • — APScheduler runs per-org analysis every 24h with idempotent job tracking and rerun-on-failure semantics.
  • — Claude synthesis stage gated on multi-detector corroboration; raw signal payloads in the prompt, told to summarize not infer.
  • — Multi-tenant PostgreSQL with row-level security on org_id; immutable append-only access audit table.
  • — Single-box deploy on AWS Lightsail Mumbai (4 GB), shared with Paperbrief. Cloudflare Origin CA terminates TLS at the edge.
  • — Full IaC in OpenTofu (Lightsail, S3, SES, IAM, SSM, CloudWatch alarms, SNS, Cloudflare DNS + Pages + Origin CA). Disaster-recovery target: 30 minutes.
  • — Nightly pg_dump to S3 with 30-day retention; backup + restore scripts auto-resolve the bucket via sts:GetCallerIdentity so the same scripts work across accounts.

Not yet shipped: a Slack / email digest channel, a per-finding feedback loop that retunes detector thresholds, paid-plan billing UX. The architecture supports all of these — they’re sequencing decisions, not unsolved problems.

Building something with this shape — multi-tenant AI product, scoped third-party integration, structural data isolation, daily scheduled analysis under a single-box budget?

Let’s talk.

Book a call →