Workspace isolation and access control
Application data is scoped by workspace. Supabase row-level security policies restrict authenticated reads to workspace members, while owner/admin checks protect sensitive mutations. Foreign keys and server-side scope derivation reduce cross-workspace mixing. Anonymous browsers receive no direct table privileges for Website Chat; narrow server-side operations derive the workspace from a strong public channel identifier.
Secrets and integration credentials
Supabase service-role credentials, OpenAI keys, Google OAuth client secrets, and Calendar encryption keys are server-only environment variables and are not prefixed for browser exposure. Google access and refresh tokens are encrypted at rest using AES-256-GCM with a server-held 32-byte key. Browser-visible connection data is limited to safe metadata; credential and OAuth-state tables have no browser grants.
OAuth and connected resources
The Calendar flow uses a cryptographically random, hashed, one-time OAuth state bound to the actor and workspace, a fixed validated callback path, a ten-minute expiry, server-side code exchange, and same-origin checks for mutations. Requested scopes are limited to calendar discovery, free/busy, and events owned by the authorizing user. Calendars are disabled until approved, and event creation must be separately enabled for an eligible owned calendar and requires approval.
AI runtime and logging boundaries
Requests and conversation history are size-bounded. The model provider is selected on the server, and the browser cannot choose arbitrary models or submit credentials. OpenAI Responses requests set store to false. Operational logs use request/source/workspace identifiers, duration, counts, outcomes, and bounded failure codes; implementation logs avoid document text, embeddings, credentials, and customer messages.
Website ingestion safeguards
Website ingestion accepts only HTTP/S public destinations, rejects credentials in URLs and local, private, link-local, multicast, reserved, and documentation IP ranges, validates redirects, enforces same-site discovery, filters sensitive utility paths, restricts content types and response sizes, and applies redirect, time, page, character, and chunk limits. Robots rules are checked as a bounded courtesy.
The current hostname-based transport leaves a narrow DNS-rebinding window between validation and connection. Deployments needing a hard egress guarantee should add an enforcing egress proxy; AGENEON does not overstate this control.
Sessions and public channels
Authentication sessions are managed through Supabase SSR cookies and validated server-side. Website Chat uses random client session tokens stored only as hashes, origin allowlists, isolated iframes, bounded bodies, per-session/channel abuse counters, no-store responses, and narrow CORS headers. No visitor fingerprinting is intentionally implemented.
Infrastructure and resilience
The service relies on managed Supabase and configured deployment infrastructure. Production hosting provider, project regions, backup configuration, incident procedures, and recovery objectives require owner confirmation. We do not claim SOC 2, ISO 27001, HIPAA, PCI certification, a completed penetration test, or a security guarantee.
Report a vulnerability
Report suspected vulnerabilities privately through the verified support channel included in AGENEON onboarding or account correspondence and mark the message “Security vulnerability.” Include affected URL, impact, reproducible steps, and a safe proof of concept. Do not access data that is not yours, disrupt service, use social engineering, or publicly disclose an unresolved issue. A dedicated security address is recommended but not represented as active until owner confirmation.