DEV Community: Diana Aliya

Build, Ship, Shape: Amazon Developer Hackathon

Diana Aliya — Tue, 13 Oct 2026 21:38:35 +0000

Alguard: a two-tier trust layer for agentic purchases

I just submitted Alguard to the
Amazon Developer Hackathon (Alexa+ track). This is a short write-up of the
architecture and the reasoning behind it.

The problem

An agent that can spend money is an agent that can be prompt-injected.
Classic defenses (LLM guardrails, prompting) are advisory — a
sufficiently clever injection gets around them. If Alexa+ can "just buy
it," the failure mode is real money lost.

The invariant

The system that requests a risky action is never the system that
approves it.

This is a structural rule, not a prompt. It shapes the whole server.

Two tiers

Tier 1 — the MCP server (mcp_server/server.py). Exposes exactly
three tools over Streamable HTTP (MCP spec 2025-11-25):

attempt_purchase
get_session_status
get_audit_trail

No approve tool. Not hidden, not guarded — absent from the schema.

Tier 2 — the human channel (web_api/resolve_action.py). A separate
FastAPI service on port 8010, behind its own OAuth audience and its own
approve scope. The only place a HALTED action can be resolved.

There is no network path from Tier 1 to Tier 2. The customer carries an
action_id by hand.

The risk engine

Every attempt is scored on:

Category severity — gift cards, crypto, wire transfers are High; groceries are Low
Anomalies — new merchant, amount spike vs. history, frequency spike, retry-after-halt
Owner trust — bumped +0.03 on approval, -0.15 on denial

Plus hard rules that no amount of trust bypasses: >$1000 single purchase,

$1500/h, >$3000/24h, High-severity category, retry-after-halt within 24h,
$250 at an unapproved merchant.

What made this hard

Concurrency. Two concurrent approvals must yield exactly one winner.
The resolver is a single conditional UPDATE with a rowcount == 1 check.

Crash consistency. If the process dies between "approved" and
"fulfilled," reconcile_unfulfilled() heals it on startup — idempotently.

Cross-process dedup. The in-process lock is a fast path, not the
guarantee. insert_action_if_not_duplicate() runs check + insert inside
BEGIN IMMEDIATE.

Bedrock is non-critical. The explanation text is generated by
converse, but a Bedrock failure never changes the decision — the
fallback template is honest about what it is (source = local-fallback).

Red-team

demo/showcase.py runs 15 attacks a hostile agent would try — category
lying, laundering a halt by retrying, session_id rotation, NaN amounts,
serial overspend. All caught. ALL ATTACKS HANDLED.

What I'd build next

Wire resolve_pending_action to a real charge (Checkout / ChargePermissionId)
Replace the text-heuristic category inference with MCC data
Split the shared SQLite into per-tier stores
Add EWMA-based drift detection (the current check catches spikes, not slow upward drift)

Repo:

Agents for Humans

Diana Aliya — Sun, 13 Sep 2026 18:02:46 +0000

The Problem, In One Sentence

Data catalogs are excellent at telling you your data is broken. They are considerably worse at actually fixing it. Someone still has to write the SQL, get it reviewed, and ship it. Albugent tries to close that specific gap.

What It Does

It scans SQLite datasets, finds the classics—negative billing amounts, NULL patient names, exposed PII—and generates a targeted fix for each. No giant, all-or-nothing SQL script. Just one isolated fix per problem, where you click Approve or Reject and move on. There's also a full CLI mode where an agent investigates everything on its own and opens a GitHub PR with a written report.

And Here's the Part I Actually Care About

The agent never touches the database. Not because it was told not to in a system prompt, but because it cannot. No write-access function is exposed to its runtime. Only a plain Python function, triggered strictly by a human clicking Approve, can execute any writes.
I went back and forth on whether this was overkill for a hackathon demo. It was not. The one time I let a patch auto-apply, it overwrote a legitimately empty column—a delivery date for an order still in transit—with a default value, because the logic hadn't yet learned the difference between "this is broken" and "this is just what normal looks like sometimes." Small bug on a demo dataset, but absolutely unacceptable in production.
The point is: don't ask the model to be careful. Just don't give it the capabilities to be careless.

Things That Actually Broke (Said With Love)

A risk-scoring function had a parameter mismatch that silently zeroed out risk scores for a while, and I didn't notice because the flat numbers looked fine. A date-matching check happily paired two unrelated date columns together because it only asked "does this look like a date," never "should these two go together." Neither of these is a dramatic bug, but both would've been mortifying to demo if I hadn't caught them.

What I'd Tell Someone Doing This Next

Don't let the LLM do arithmetic or decide what "risky" means through vibes and a hopeful prompt when you can just compute it. Save the model for what's genuinely hard to hardcode—prioritizing the investigation or writing summaries humans actually want to read. Everything else with exactly one correct answer belongs in code, not in a model that is confidently wrong exactly as often as it is confidently right.

Thanks
Special thanks to AWS for hosting this hackathon, providing access to Bedrock, and building the infrastructure around Strands and MCP that made integrating agentic workflows into this architecture so seamless.
Project Links

GitHub Repository
3-Minute Demo Video
Engineering Retrospective on DEV.to

Albuget WebMCP

Diana Aliya — Mon, 07 Sep 2026 17:32:23 +0000

Submitted my entry for the WebMCP Challenge: Albugent WebMCP.

Traditional data governance tools usually require shipping sensitive datasets to external servers to scan for PII and compliance risks. I wanted to see if we could do the entire pipeline locally, right inside the browser.

Albugent runs SQLite WASM inside a Web Worker. All SQL queries, anomaly profiling, and data masking happen strictly in browser RAM—zero data leaves the client. The AI agent registers tools natively using the document.modelContext WebMCP API, scans for unmasked PII, and proposes SQL remediation scripts. The human engineer always stays in the loop to review and approve the SQL before anything executes.

Building a zero-backend governance engine with reactive state sync between WASM worker threads and React was definitely an intense engineering sprint, but really rewarding to see working end-to-end.

What’s Next:
Albugent was built as a privacy-first proof-of-concept to show what’s possible when WASM and AI agents run entirely on the client. To turn this into a fully usable, zero-cost utility for everyone, the next step on the roadmap is adding a BYOK (Bring Your Own Key) option and local model support (via Ollama/WebLLM), along with drag-and-drop CSV and SQLite file loading.

If you'd like to try it out or look through the code:

Live App: albugent • GitHub: evaaliya • Demo Video: matricula

Thanks to the team behind the WebMCP Challenge for organizing this!

P.S. Built this as a true human-AI collaboration — shoutout to AI coding tools for acting as a 24/7 pair programmer throughout the build.