PromptShield AI – An AI Cost & Risk Firewall Built with Xano
Source: Dev.to
Architecture Overview
| Component | Technology |
|---|---|
| Backend | Xano (Postgres, APIs, background jobs, AI workflows) |
| Frontend | Lovable.dev (low‑code SaaS dashboard) |
| AI‑first approach | Backend generated with AI, refined by hand |
| Public API + Admin UI | Production‑ready by design |
Demo
Demo Walkthrough Video
(Video link omitted – replace with actual video when available)
Product Screenshots
The dashboard shows real API keys, budgets, policies, providers, and usage analytics powered entirely by Xano.
AI Prompt I Used (Backend Generation)
All backend workflows, API definitions, and schema refinements are tracked in the GitHub repository below for transparency and reproducibility:
👉
I used XanoScript with an AI‑first workflow to generate the initial backend. Below is the original prompt used to bootstrap the system:
You are an expert backend architect building a production-ready, multi-tenant AI infrastructure backend using Xano.
Build a backend called "PromptShield AI" — an AI Cost & Risk Firewall that sits between applications and multiple LLM providers (OpenAI, Anthropic, etc.) to enforce budgets, rate limits, and safety policies before requests reach the LLM.
The backend must be secure, scalable, and suitable for public API consumption.
Create the initial backend for PromptShield AI with the following requirements:
1. Core Concept
PromptShield AI acts as a proxy API for LLM calls. Applications send standard chat/completion payloads to PromptShield, which enforces usage policies, budgets, and risk checks before forwarding requests to LLM providers.
2. Database Schema (Postgres)
Design tables for:
- tenants (org_id, name, plan, created_at)
- api_keys (key, tenant_id, status, last_used_at)
- users (user_id, tenant_id, role)
- llm_providers (provider, model, cost_per_1k_tokens)
- usage_logs (tenant_id, user_id, feature, provider, model, tokens_in, tokens_out, cost, timestamp)
- budgets (tenant_id, scope_type, limit_amount, period, reset_at)
- policies (policy_id, tenant_id, type, rule_json, enabled)
- ... (additional tables as needed)
3. API Endpoints
Define RESTful endpoints for:
- /v1/chat (proxy chat request)
- /v1/completions (proxy completion request)
- /admin/keys (CRUD API keys)
- /admin/budgets (CRUD budgets)
- /admin/policies (CRUD policies)
- /admin/usage (retrieve usage analytics)
4. Business Logic
- Validate API key and associate request with tenant.
- Check tenant’s budget; reject if limit exceeded.
- Run prompt through safety policy engine; block if risky.
- Select cheapest provider/model that satisfies policy constraints.
- Forward request, capture token usage, compute cost, store in usage_logs.
- Return response to caller.
5. Security & Scalability
- Rate‑limit per API key.
- Store secrets securely (e.g., encrypted columns).
- Use background jobs for async logging and billing.
- Design for horizontal scaling (stateless API layer).
Provide the XanoScript code snippets, schema definitions (SQL), and example API specifications (OpenAPI v3). 










