PromptShield AI – An AI Cost & Risk Firewall Built with Xano

Published: (December 14, 2025 at 11:51 AM EST)
3 min read
Source: Dev.to

Source: Dev.to

Architecture Overview

ComponentTechnology
BackendXano (Postgres, APIs, background jobs, AI workflows)
FrontendLovable.dev (low‑code SaaS dashboard)
AI‑first approachBackend generated with AI, refined by hand
Public API + Admin UIProduction‑ready by design

Demo

Demo Walkthrough Video

(Video link omitted – replace with actual video when available)

Product Screenshots

Screenshot 1

Screenshot 2

Screenshot 3

Screenshot 4

Screenshot 5

Dashboard Overview

API Key Management

Tenant Management

Budget Management

Provider Management

Usage and Analytics

Policy Management

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). 
Back to Blog

Related posts

Read more »