Security Overview

AgencyOS holds commercially sensitive material: client relationships, contracts and pricing, call recordings, invoices and employee records. Our security approach is built on four ideas — isolate data in the database rather than only in the application, give every user the least access their job needs, encrypt data in transit and at rest, and keep a record of what happened.

• The application is a browser-based client that talks to a managed PostgreSQL backend and to server-side functions. There is no self-managed server for customers to patch.
• Infrastructure — database, authentication, object storage and serverless functions — runs on Supabase, which builds on hardened cloud infrastructure with physical security, network controls and platform patching handled by the provider.
• Server-side logic that must not run in the browser — telephony control, payment checkout, AI calls, credential handling, email and SMS dispatch, scheduled jobs — runs in isolated edge functions with their own secrets, never exposed to the client.
• Files and recordings are stored in access-controlled object storage rather than on disk next to the application.

Access rules are enforced in the database, not only in the user interface. Row Level Security is enabled across the application schema, and access to each table is expressed as explicit policies evaluated on every query against the identity of the requesting user.

• A query issued with a user's session can only return rows that user's policies allow — even if the request is crafted by hand rather than sent by the application.
• The elevated service role key used by server-side functions is never shipped to the browser and is only used by trusted server-side code paths.
• Public links — shared contracts, signature pages, presentations, calendar feeds — are reached through single-purpose, server-verified tokens that expose only the specific document they belong to.

Sign-in

• Authentication is handled by the managed auth service. Passwords are stored only as salted hashes; we never see or store them in readable form.
• Password resets are performed through single-use, time-limited tokens delivered by email, with minimum complexity enforced when the new password is set.
• Where your organisation signs in through the external authentication bridge, requests are restricted to allow-listed domains, authenticated with a shared secret, rate limited per IP address, and logged. Any additional factors enforced by your own identity provider continue to apply.
• Sessions expire after a period of inactivity — 30 minutes by default, adjustable by workspace administrators — after which the user is signed out.

Authorisation

• Access is role-based. Users hold one or more roles, and administrators can grant or revoke access to individual areas of the application through per-tab permissions.
• Route guards prevent a user from opening an area their role does not cover, and the matching database policies stop the underlying data from being returned even if the interface is bypassed.
• Users who legitimately hold more than one function can switch between role profiles; each switch is an explicit, recorded action rather than an implicit widening of access.

• In transit. All traffic between the browser, the API, edge functions and third-party providers uses TLS. The application is served over HTTPS only.
• At rest. Database contents, object storage and backups are encrypted at rest by the hosting platform.
• Application-level. Stored third-party credentials are additionally encrypted with AES-256-GCM using a random initialisation vector per value, with the key held server-side in the function environment and never available to the browser.

• API keys for telephony, AI, email, payment and accounting providers live in server-side function secrets. They are never bundled into the client application.
• The browser only ever receives the public, publishable API key, whose capabilities are constrained by the database policies described above.
• Credentials entered by users for external systems are encrypted before storage and decrypted only inside a server-side function at the moment of use.
• Secrets are rotated when a provider is changed, when staff with access leave, or on suspicion of exposure.

• Inbound webhooks from telephony, meeting and payment providers are verified before being acted on — signature verification against the provider's public key or shared secret, depending on what the provider supports.
• OAuth connections (mailbox, accounting) request only the scopes a feature needs, and tokens are stored encrypted and are revocable by the user at any time by disconnecting the integration.
• User-supplied content rendered in the application is sanitised before display to prevent script injection.
• Cross-origin access to server-side functions is restricted, and sensitive endpoints require a valid session.

• Significant actions in a workspace are recorded with the acting user and timestamp, so administrators can reconstruct who changed what.
• Dialer activity keeps its own audit trail — calls placed, outcomes, do-not-call changes and configuration changes.
• Server-side functions log operational events for debugging and security review. Logs are retained for a limited period proportionate to that purpose and are access-controlled.
• We aim to keep secrets, tokens and full personal records out of logs; where diagnostics require identifiers, we log the minimum needed.

• The database is backed up on the managed platform's schedule, with point-in-time recovery available on supported plans. Backups are encrypted and retained on a rolling cycle of roughly 30 days.
• Restores are performed by the platform provider on our request in a recovery scenario.
• Customers can export their own data from the application at any time — records, reports and documents — so a copy can be kept outside the platform.
• Because delivery depends on third-party carriers and AI providers, an outage at one of them may degrade a specific feature without affecting the rest of the platform.

• Changes are version controlled, reviewed before release, and deployed through a repeatable pipeline.
• Database changes ship as reviewed migrations, so access policies change deliberately and are auditable.
• Static analysis and type checking run over the codebase, and automated tests cover core logic.
• Dependencies are updated regularly, and known-vulnerable packages are prioritised for patching.
• Production data is not used for development or testing.

• Access to production systems is limited to the small number of staff who need it for operations and support, and is granted on a least-privilege basis.
• Staff access is removed promptly on role change or departure.
• Staff are bound by confidentiality obligations, and sub-processors are engaged under written data protection terms.
• We access a customer workspace only to provide support, to investigate a security issue, or where legally required.

• Suspected incidents are triaged on receipt, with containment prioritised over analysis.
• Where a personal data breach affects data we process for a customer, we notify that customer without undue delay and in any event within 72 hours of becoming aware, with the detail needed for their own regulatory notifications.
• After containment we identify root cause, remediate, and record the outcome so the same failure does not recur.

We are transparent about what we do and do not currently hold, so that reviewers can assess us accurately:

• In place: GDPR-aligned processing as a data processor for Customer Data, a Data Processing Agreement available on request, a documented sub-processor list, EU Standard Contractual Clauses for transfers outside the EEA, and the technical measures described on this page.
• Not claimed: we do not currently hold a SOC 2 Type II report or ISO/IEC 27001 certification, and we do not claim HIPAA or PCI DSS scope. Card data is handled entirely by our payment processor and never touches our systems.

If your procurement process requires an assurance report or a specific control framework, contact us — we would rather tell you plainly where we stand than have you assume.

Security of a workspace is shared. As the customer, you are responsible for:

• assigning roles and per-area permissions that match what each person actually needs;
• removing accounts promptly when people leave, and not sharing logins;
• setting the session inactivity timeout appropriately for your environment, particularly on shared machines;
• deciding what data belongs in the platform — including whether to record calls and whether to store sensitive documents;
• configuring do-not-call lists, quiet hours and recording notices to match the law where you operate;
• reviewing which integrations are connected and revoking those you no longer use;
• controlling who receives public share links for contracts, presentations and calendar feeds.

We welcome reports from security researchers and customers. Email taras@agencyos.tech with steps to reproduce, the impact you believe it has, and how we can reach you.

• We acknowledge reports within 3 business days and keep you updated until the issue is closed.
• Please give us reasonable time to fix an issue before disclosing it publicly, and do not access, modify or delete data that is not yours while testing.
• Please do not run automated scanning or load testing against production without our written agreement — it is indistinguishable from an attack.
• We will not pursue legal action against researchers who act in good faith and follow these guidelines.

For urgent matters affecting live data, mark the subject line URGENT and include a contact number. Provider: SY Consultancy ApS (CVR no. 41963972), C/O VXC, Amaliegade 45, 1., 1256 København K, Denmark.