Security

Every agent operates in its own silo. An agent's API key grants access only to that agent's calendar and events. There is no cross-agent data access — an API key for Agent A cannot read, write, or delete data belonging to Agent B, even if both agents belong to the same user.

Isolation is enforced at the database query level: every API request is scoped to the authenticated agent's calendar via foreign key relationships, not just application logic.

API keys are generated using cryptographically secure random values (40-character nanoid) and prefixed with ak_ for easy identification.

• Hashed storage: Only the SHA-256 hash of your key is stored. The plaintext key is shown once at creation and never persisted.
• Rotation: You can regenerate an API key at any time from the agent settings tab. The old key is immediately and permanently revoked.
• No retrieval: Lost keys cannot be recovered — only regenerated. This is by design.

Dashboard access is protected by Clerk, an industry-standard authentication provider. Clerk handles password management, session tokens, and multi-factor authentication.

All dashboard API routes verify your Clerk session and confirm resource ownership before granting access. You can only manage agents you created.

Every operation that modifies or reads agent data follows a strict ownership chain:

1. Authenticate the user (Clerk session or API key).
2. Look up the resource in the database.
3. Verify the resource belongs to the authenticated user or agent.
4. Only then execute the operation.

This applies to agents, calendars, events, and subscriptions. No shortcuts — ownership is checked on every request.

Calendar subscription URLs contain a 32-character random token that acts as a bearer credential. Tokens can be:

• Rotated: Generate a new token from the agent settings tab. The old URL stops working immediately.
• Revoked: Delete a subscription to permanently disable access.

Subscription URLs are designed to be shared with calendar apps (Google Calendar, Apple Calendar, etc.) and should be treated like read-only access tokens.

All data is stored in a Neon PostgreSQL database with encryption at rest enabled by default. All connections use TLS.

Incoming Clerk webhooks are verified using Svix signature validation. This prevents spoofed webhook events from creating or modifying user records.

Rate limiting on API endpoints is planned. This will protect against brute-force attacks and abuse. Until then, API keys provide the primary access control.