Permissions, scopes & security

AI Connect’s security model has one rule at its core: an AI connection is a WordPress user. Every OAuth connection signs in as a real account on your site, every Connection key is tied to the user who generated it, and every tool call passes through the same capability checks the wp-admin screens use. The AI can never do more than the connected human could.

Two layers on every call

1. Scope – what the connection was approved for on the consent screen.
2. Capability – what the connected WordPress user is allowed to do (e.g. manage_venuera_events, venuera_pos).

Both must pass. Better still, the tool catalog itself is filtered: an assistant connected as a cashier doesn’t just get refused event editing – it never even sees those tools in its list.

The four scopes

The consent screen offers these scopes, each with its own checkbox (approve only what you want that connection to have – if nothing is ticked, the connection defaults to read-only):

• venuera:read – read data from all Venuera add-ons: events, tickets, attendees, schedules, seating availability, ticket designs and sales reports.
• venuera:write – create and update across all Venuera add-ons: events, ticket types, schedules, attendee fields, ticket designs and seating charts (new content starts as draft).
• venuera:checkin – scan tickets and manage check-in at the door.
• venuera:pos – point of sale: sales reports, sessions and shifts; creating orders and refunds always requires an extra confirmation step.

OAuth 2.1, done properly

• Authorization Code flow with PKCE (S256) – required, no exceptions.
• Dynamic Client Registration so Claude and ChatGPT set themselves up without manual configuration (can be disabled in Settings if you use Connection keys exclusively).
• Access tokens live 1 hour; refresh tokens live 30 days and rotate on every use. Replaying an old refresh token trips reuse detection and revokes that connection’s whole token family.
• Tokens are stored only as SHA-256 hashes – a database leak exposes no usable secrets.
• Authorization codes are single-use and expire in 60 seconds; redirect addresses are exact-matched against the client’s registration.

Guard rails on write operations

• Draft-first: events and ticket types the AI creates are always WordPress drafts with an edit link – a human presses publish.
• Two-step money: POS orders and refunds require a prepare step that returns a summary and a single-use confirmation token (valid 10 minutes). Nothing is charged or refunded until the human approves and the confirm tool is called.
• Reversible deletes where possible: deleting events or ticket types moves them to the WordPress Trash; tools refuse to touch anything with sold tickets unless explicitly forced.
• Destructive tools are flagged to the client (undo check-in, replace a recurrence rule, delete a chart), so well-behaved assistants ask before acting.

The off switches

• Revoke (Connections tab) – kills one connection instantly; its next call gets a 401.
• Read-only mode (Settings) – one checkbox hides every write tool from every connection. Handy during a live event when you want answers but no changes.
• AI access enabled (Settings) – the master switch. Off means the endpoint answers 503 for everyone; tokens and connections survive, so switching back on resumes exactly where you left off.

The audit trail

Every tool call is logged: time (UTC), WordPress user, client, tool name, outcome, duration and (optionally) arguments – see the Activity tab. Arguments logging can be turned off for privacy, but write-tool arguments are always kept. Entries are pruned automatically after the retention period (default 90 days), and generated export files are deleted from the server after 24 hours.