C1
Your Google tokens never touch our application database.
Tokens are written to a per-user encrypted secret store, separate from the database that holds your account record.
// trust & security
independently assessed.
every 12 months.
TAC Security CASA Tier 2 · Google OAuth verified · Data hosted in Australia.
What we're assessed against: Google's Cloud Application Security Assessment, aligned to OWASP ASVS V1–V14. CASA Tier 2 is a Letter of Validation, valid 12 months — not a SOC 2 or ISO 27001 certification, both of which are on our path to GA.
// what this covers
- The Liv web app at
app.liv4all.com— the surface that holds your tokens. - The full Google OAuth lifecycle — consent, storage, use, revocation.
- Application security controls per OWASP ASVS V1–V14.
// section B · compliance
what CASA Tier 2 actually means
CASA (Cloud Application Security Assessment) Tier 2 is the security review Google requires for any app that handles restricted Gmail scopes. It's an OWASP-ASVS-aligned assessment performed by a Google-authorised lab and includes static analysis (SAST), dynamic analysis (DAST), and a manual architecture review.
Liv reads and drafts email on your behalf. Google rightly classifies that as a restricted scope, so an independent lab — TAC Security — assessed our app, infrastructure, and data flows end-to-end. The Letter of Validation is available on request: email support@liv4all.com and we'll reply with the document.
What that means for you: an outside party — not Liv's founders — verified that the way we store your Google tokens, the way we isolate your data from other users', and the way we expose our app to the internet meet a published industry bar. The Letter of Validation is re-issued every 12 months for as long as we keep that bar.
// assessment scope
your browser
Liv's edge
Liv's web app
encrypted secret store
Google APIs
Every hop above — including the boundary between the web app and the secret store — was in scope for the assessment.
// section C · data handling
how we handle your data
Five answers to the questions a security-conscious person actually asks before connecting Gmail.
C2
Tokens are never returned to your browser.
The dashboard shows only the names of vault entries, never the values. The same applies to OAuth tokens — they are used by the agent and never round-tripped through the browser.
C3
Modern TLS from your browser to Liv.
We accept TLS 1.3 only, redirect HTTP to HTTPS, and ship HSTS. Certificate-chain and load-balancer details are audited as part of the assessment rather than published here.
C4
We hold the minimum Google scopes we need.
calendar.readonly, calendar.events, contacts.readonly, gmail.modify — nothing else. These are the same scopes Google shows you on the consent screen.
C5
You can disconnect Google in one click.
The disconnect button calls Google's revoke endpoint and removes the corresponding secret from our store in the same request.
// section D · architecture
architecture & isolation
Two design properties carry most of the weight here. Both are enforced by the surrounding infrastructure, not by the application — the app couldn't break them by accident if it tried.
D1
your data lives in your own walled garden
- One operator, one runtime. Every operator gets their own dedicated agent runtime. Code execution, memory, and storage are not shared with any other operator.
- Least-privilege identity per operator. Each runtime carries permissions scoped exclusively to that operator's mailbox prefix and outbound mail address. Cross-user reads and cross-user sends are rejected at the infrastructure layer, not just the application layer.
- Filesystem isolation, enforced below the application. An operator's files are only visible inside that operator's runtime. The boundary is enforced by the platform itself — the application can't accidentally step over it because the surrounding infrastructure won't allow it.
- No public ingress to the data plane. Internet traffic terminates at our edge; the database, secret store, and agent runtimes have no public network endpoints.
D2
secrets the agent itself cannot read
- The agent process is denied direct access to user vault entries at the platform layer; it cannot fetch them on its own.
- When an outbound call genuinely needs a credential, a separate broker resolves it on the agent's behalf — only for the duration of that one call, and only for the operator that owns it.
- A prompt-injected agent that tries to dump its own environment or read its own files finds nothing useful. The credentials aren't there to begin with.
// section E · AI safety
AI-specific safety
The failure modes people fear with an AI agent are different from a normal SaaS product — a runaway loop, an injected prompt, a confidently-wrong send. We treat them as a real risk class and design around them.
draft-first email
Liv never silently sends email. Every outbound message is drafted and surfaced to you in Telegram for explicit approval. No surprise sends, ever.
allowlisted Telegram
Each user's bot only accepts messages from the owner's Telegram user ID. Strangers messaging the bot are dropped — bounding the blast radius of any attempt to social-engineer the agent through its own messaging channel.
per-user spend caps
Every operator's agent runs against a hard per-operator inference budget. A runaway loop or hostile prompt cannot rack up unbounded model spend — not on someone else's account, not on Liv's.
prompt injection — modelled, not ignored
Indirect prompt injection (adversarial content in emails, web pages, or calendar invites the agent reads) is a real risk class. We mitigate it with the properties above: human-in-the-loop on outbound mail, allowlisted messaging, and least-privilege secret access. Defence-in-depth is the only honest answer.
// section F · sub-processors
sub-processors
Vendors that process operator data on Liv's behalf. We list the vendor and the region — not the specific managed services we use inside each vendor.
| Sub-processor | Purpose | Region | Data class |
|---|---|---|---|
| AWS | Cloud hosting, storage, secret management, transactional email | Australia (Sydney) | Account data, OAuth tokens, operational logs |
| OAuth + Gmail / Calendar / Contacts APIs the operator authorises | Google global | OAuth tokens, operator email | |
| Telegram | Operator's chat channel | Telegram global | Operator chat IDs and messages |
| Anthropic | LLM inference (Claude) | Anthropic global | Conversation content |
| AWS Bedrock | LLM inference (Claude, fallback) | AWS Bedrock global | Conversation content |
| Browserbase | Headless web browsing on the operator's behalf | US | URLs fetched |
| Brave Search | Web search | US | Search queries |
| TAC Security | CASA Tier 2 assessor | Global | No runtime data; sees code and staging during the audit window only |
// notification commitment
We commit to 30 days advance notice before adding any new sub-processor that processes operator data, with one carve-out: where a change is required for service continuity — for example, a primary provider becoming unavailable — we will notify affected operators within 7 days of the change. Notifications are sent by email to the address on file for each active operator account.
See our privacy policy for the full data-handling story, including retention and your rights.
// section G · disclosure
vulnerability disclosure
Found something? We'd like to hear from you. Researchers acting in good faith will not be pursued — see the safe-harbour clause below.
// contact
security@liv4all.com
Please email security@liv4all.com with a description of the issue, reproduction steps, and any artefacts (logs, screenshots, proof-of-concept) you can share. PGP-encrypted reports welcome on request.
// response window
3 business days to acknowledge
We'll acknowledge a report within 3 business days and provide an initial assessment within 10 business days. Severity-driven remediation timelines follow from there, and we'll keep you in the loop.
// safe harbour
We will not pursue legal action against researchers who, in good faith, follow this policy: avoid privacy violations, destruction of data, and degradation of service; only interact with accounts you own or have explicit permission to test; give us reasonable time to remediate before public disclosure; and don't exploit any vulnerability beyond what's necessary to demonstrate it.
Out of scope: denial-of-service, social-engineering of staff, physical attacks on infrastructure, and findings on third-party services where Liv has no remediation path.
// section H · resources
frequently asked
Is Liv SOC 2 certified?
Not yet. CASA Tier 2 covers the OAuth-touching application surface per OWASP ASVS. SOC 2 Type II is on our path to GA.
Where is my data stored?
Australia (Sydney). We do not currently offer multi-region residency.
Can I export or delete my data?
Yes. Disconnecting Google revokes the tokens with Google and removes the corresponding entries from our secret store. A full account-deletion request to support@liv4all.com tears down your account record, your dedicated agent runtime, and every credential we hold for you. Operational logs are retained for the period documented in our privacy policy.
What model does Liv use?
Claude (the latest GA Sonnet model from Anthropic). We do not train models on your data; Anthropic's enterprise terms apply.
Does the embed widget see my dashboard data?
No. The public widget runs against a separate, isolated knowledge-base service that has no access to operator data.
How often is the Letter of Validation refreshed?
Annually. We've set a calendar reminder ten months out so the re-scan is in flight before the current LoV expires.