Skip to main content

​
Security & Trust

Agentbot is committed to keeping your data safe. Here’s our security posture.

​
Security Overview

​
Skill Security Matrix

​
Bot detection

Sensitive API endpoints are protected by bot detection to prevent automated abuse. Protected endpoints return a 403 status code when a request is identified as coming from an automated source. Protected endpoints: Requests from standard web browsers are not affected. Automated clients such as scripts or bots may be blocked. If you are building a legitimate integration and receive a 403 response, ensure your requests originate from an environment that supports browser-level verification.

​
Trust Principles

​
1. Minimal Data Collection

  • We don’t store prompts or generated images permanently
  • Demo skills use in-memory data that resets on restart
  • No user data sent to third parties (except Replicate for image generation)

​
2. Input Sanitization

All user inputs are:
  • Length-limited (max 100-500 chars depending on field)
  • Type-checked (strings, arrays, numbers)
  • Allowlist-validated (enum values must match predefined lists)
  • HTML/JS stripped (<> characters removed)

​
3. API Key Security

  • Replicate API tokens stored in server-side environment variables
  • Never exposed to client-side code
  • Used only for image generation requests

​
4. Read-Only Skills

Track Archaeologist, Setlist Oracle, Royalty Tracker, Venue Finder, Festival Finder, and Event Scheduler are read-only:
  • No user data stored
  • No external API calls
  • Uses only in-memory mock catalog
  • Safe for public demo use

​
Row-level security

All user-scoped database tables are protected by PostgreSQL row-level security (RLS) policies. Each authenticated request sets a user context at the database level before any query executes, so users can only read and modify their own data.

​
Protected tables

​
Admin bypass

Users with the admin role bypass RLS policies and can access all rows across tenants. Admin access is determined by the role column on the User table.

​
How it works

  1. The auth middleware verifies the JWT and extracts the userId.
  2. Before any database query, the middleware calls set_current_user_id(userId) to set a PostgreSQL session variable.
  3. RLS policies on each table compare the row’s userId (or id for the User table) against the session variable.
  4. Queries automatically return only rows belonging to the authenticated user.
RLS is enforced at the database level and cannot be bypassed by application code. Even if a query omits a WHERE clause, only the authenticated user’s rows are returned.

​
Auth middleware

The backend API uses a JWT-based auth middleware that runs before protected endpoints.

​
Authentication flow

  1. The client includes a Bearer token in the Authorization header.
  2. The middleware verifies the JWT signature and expiration.
  3. On success, the middleware attaches userId, userEmail, and userRole to the request and sets the RLS context.
  4. On failure, the endpoint returns one of the error codes below.

​
Error codes

​
Admin endpoints

Endpoints that require admin access use an additional requireAdmin check after authentication. Non-admin users receive a 403 response with code ADMIN_REQUIRED.

​
Web API security middleware

The web frontend wraps API routes with security middleware that provides:
  • Rate limiting — per-IP request limits
  • DDoS protection — automated request filtering
  • Bot detection — blocks automated abuse on sensitive endpoints
  • SQL injection prevention — request parameters and body are scanned for injection patterns
  • XSS prevention — payloads containing script tags or event handlers are rejected
  • JSON validation — Content-Type enforcement and body parsing on mutation endpoints
  • CSRF protection — token-based verification using the x-csrf-token or x-xsrf-token header

​
Route protection levels

​
Error codes

​
Known limitations

​
Demo mode

Currently skills run in demo mode. In production:
  • API rate limits will be per-user

​
In-Memory Storage

Groupie Manager uses in-memory Map storage. Data is:
  • Lost on server restart
  • Not shared between server instances
  • Only for demonstration purposes

​
Reporting Issues

Found a security issue? Email security@raveculture.xyz or open a GitHub issue.