Loading AGENEON...
Loading AGENEON...
Security & Trust
A plain-language overview of the controls inside your workspace. The formal detail lives in our legal pages.
01
You choose which actions AGENEON takes on its own and which wait for a person. Anything marked for approval is not sent until someone decides.
Waiting for a personExample
02
Every message and action carries its author: the customer, AGENEON, or a named colleague. A colleague's words are never shown as AGENEON's, or the reverse.
Conversation historyExample
03
People see the workspace their role allows. Decision controls appear only for those allowed to decide; a member sees the same workspace without them.
Who can decideExample
04
Each business works in its own workspace. An agency reaches a client's workspace only with access the client approves, per person — and the client can revoke it at any time.
Access to your workspaceExample
05
You can request deletion of your data under our Data Deletion policy. Moving to a smaller plan never deletes anything.
Your dataExample
06
Your workspace shows the exact state of each connection. If an allowance runs out, AGENEON pauses its own AI work — your team keeps replying and nothing is deleted.
ConnectionsExample
Legal
Our legal pages are the authoritative source.
Last updated: August 24, 2026Effective: August 24, 2026
AGENEON uses layered technical controls evidenced by the current implementation. This page describes those controls without claiming certifications, audits, penetration tests, or guaranteed security.
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.
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.
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.
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 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.
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.
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 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.