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
- The auth middleware verifies the JWT and extracts the
userId.
- Before any database query, the middleware calls
set_current_user_id(userId) to set a PostgreSQL session variable.
- RLS policies on each table compare the row’s
userId (or id for the User table) against the session variable.
- 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
- The client includes a
Bearer token in the Authorization header.
- The middleware verifies the JWT signature and expiration.
- On success, the middleware attaches
userId, userEmail, and userRole to the request and sets the RLS context.
- 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 or open a GitHub issue.