> ## Documentation Index
> Fetch the complete documentation index at: https://raveculture-mintlify-provision-email-header-1774047024.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> Agentbot security practices and trust guarantees

# Security & Trust

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

## Security Overview

| Category          | Status | Notes                                              |
| ----------------- | ------ | -------------------------------------------------- |
| Data Encryption   | ✅      | TLS 1.3 in transit                                 |
| API Authorization | ✅      | Session-based auth + JWT middleware                |
| Data Isolation    | ✅      | Row-level security (RLS) policies                  |
| Bot Detection     | ✅      | Automated request filtering on sensitive endpoints |
| Input Validation  | ✅      | Allowlist + sanitization                           |
| Rate Limiting     | ✅      | Per-IP limits                                      |
| Audit Logging     | ✅      | All actions logged                                 |

## Skill Security Matrix

| Skill               | Input Validation | Sanitization | User Data | External Calls |
| ------------------- | ---------------- | ------------ | --------- | -------------- |
| Visual Synthesizer  | ✅                | ✅            | ❌         | ✅ (Replicate)  |
| Track Archaeologist | ✅                | ✅            | ❌         | ❌              |
| Setlist Oracle      | ✅                | ✅            | ❌         | ❌              |
| Groupie Manager     | ✅                | ✅            | ✅ (demo)  | ❌              |
| Royalty Tracker     | ✅                | ✅            | ❌         | ❌              |
| Demo Submitter      | ✅                | ✅            | ✅ (demo)  | ❌              |
| Event Ticketing     | ✅                | ✅            | ✅ (email) | ❌              |
| Event Scheduler     | ✅                | ✅            | ❌         | ❌              |
| Venue Finder        | ✅                | ✅            | ❌         | ❌              |
| Festival Finder     | ✅                | ✅            | ❌         | ❌              |

## 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:**

| Endpoint                    | Purpose                               |
| --------------------------- | ------------------------------------- |
| `/api/register`             | Prevents fake account creation        |
| `/api/auth/forgot-password` | Blocks automated password reset abuse |

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

| Table            | Policy               | Isolation key |
| ---------------- | -------------------- | ------------- |
| `User`           | `user_isolation`     | `id`          |
| `Agent`          | `agent_isolation`    | `userId`      |
| `ScheduledTask`  | `task_isolation`     | `userId`      |
| `AgentMemory`    | `memory_isolation`   | `userId`      |
| `AgentFile`      | `file_isolation`     | `userId`      |
| `InstalledSkill` | `skill_isolation`    | `userId`      |
| `AgentSwarm`     | `swarm_isolation`    | `userId`      |
| `Workflow`       | `workflow_isolation` | `userId`      |
| `Wallet`         | `wallet_isolation`   | `userId`      |
| `ApiKey`         | `apikey_isolation`   | `userId`      |
| `Account`        | `account_isolation`  | `userId`      |
| `Session`        | `session_isolation`  | `userId`      |

### 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.

<Note>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.</Note>

## 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

| Code             | HTTP status | Description                                                                   |
| ---------------- | ----------- | ----------------------------------------------------------------------------- |
| `AUTH_REQUIRED`  | 401         | No `Authorization` header or missing `Bearer` prefix                          |
| `TOKEN_INVALID`  | 401         | JWT signature verification failed or token has expired                        |
| `AUTH_ERROR`     | 500         | Unexpected error during authentication                                        |
| `ADMIN_REQUIRED` | 403         | Endpoint requires admin privileges and the authenticated user is not an admin |

### 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

| Level     | Wrapper                 | Includes                                                 |
| --------- | ----------------------- | -------------------------------------------------------- |
| Public    | `SecureRoute.public`    | Rate limiting, bot detection, input validation           |
| Protected | `SecureRoute.protected` | Public checks + session or API key authentication        |
| Mutation  | `SecureRoute.mutation`  | Protected checks + POST-only enforcement                 |
| JSON      | `SecureRoute.json`      | Public checks + POST-only + JSON content-type validation |
| Sensitive | `SecureRoute.sensitive` | Protected + POST-only + JSON validation + CSRF token     |

### Error codes

| HTTP status | Description                                                                                           |
| ----------- | ----------------------------------------------------------------------------------------------------- |
| 400         | Invalid JSON body, missing `Content-Type: application/json`, or injection pattern detected in request |
| 401         | Missing authentication credentials                                                                    |
| 403         | Invalid or missing CSRF token                                                                         |
| 405         | HTTP method not allowed (non-POST request on a mutation endpoint)                                     |
| 429         | Too many failed authentication attempts from the same IP                                              |

## 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](mailto:security@raveculture.xyz) or open a GitHub issue.