An AI can only touch what its key allows.

1. Every organization gets its own deployment

ConferenceOS isn’t a shared multi-tenant database. Each organization runs its own isolated deployment with its own database, so one customer’s events, attendees, and finances are never stored alongside another’s. Organizers can export their data and configuration, so leaving doesn’t depend on us.

2. How AI access is bounded

AI assistants connect through the Model Context Protocol (MCP) using an API key, and the key decides what the assistant can do:

• Roles. A key carries one of three cumulative roles: speaker administrator, event administrator, or system administrator. A key with no role can only read. An assistant is shown only the tools its role can use.
• Event pinning. Most keys are pinned to a single event, and a request naming a different event is refused. When a write reaches a record indirectly, for example updating a speaker through a session, the scope is checked again after the record loads, so pinning can’t be sidestepped.
• Money needs its own permission. Budget writes need a separate permission on top of the role. Being able to edit the schedule doesn’t mean being able to edit the money.
• Previews before commits. CRM and expense writes return a preview of the rows that would change by default, and commit only when the call explicitly confirms the change. Core content writes (speakers, CFP status, event details, sessions, FAQ) apply directly. They’re fully audited, but they aren’t dry-run by default.
• Audit log. Every AI tool call is recorded in an audit log.

ConferenceOS has no built-in agent that runs event operations on its own. An assistant works through a key that a person issued, and only within that key’s limits.

3. People and sign-in

People sign in through Clerk, a dedicated authentication provider, so ConferenceOS doesn’t store passwords. Organizers, speakers, sponsors, reviewers, and attendees each get a role-based portal that shows only what that role needs.

4. Payments

Tickets are sold through the organizer’s own Stripe account using Stripe’s hosted checkout. Card numbers are entered on Stripe’s pages and never reach ConferenceOS servers, and we never hold an organizer’s funds.

5. Infrastructure

• All traffic is served over HTTPS, with HTTP Strict Transport Security enabled on conferenceos.io and the demo instance.
• Deployments run on Vercel. Data is stored in PostgreSQL on Neon, which encrypts data at rest.
• The providers a deployment uses, and what each one handles, are listed in the privacy policy and on the required services page.
• Our primary dependencies are published in a machine-readable software bill of materials.

6. What we don't claim

ConferenceOS doesn’t currently hold a SOC 2 report or an ISO 27001 certification. If your procurement process needs a security questionnaire, email us and we’ll answer it directly, including the questions where the answer is “not yet.”

7. Reporting a vulnerability

If you think you’ve found a security issue in ConferenceOS or this website, email mrhinkle@peripety.com with “Security report” in the subject line. Include what you found, where, and how to reproduce it. We’ll acknowledge your report, keep you updated while we investigate, and credit you if you like once it’s fixed.

Please give us reasonable time to fix an issue before you disclose it publicly, and don’t access data that isn’t yours, degrade the service, or test against real customer deployments. Use the demo instance instead. We won’t pursue legal action against research done in good faith within these limits.

This policy is also published in machine-readable form at /.well-known/security.txt.