SECURITY / FOR PARTNERS

Your business owners' data is yours. Isolated by design, not by promise.

How the work behind your brand keeps each partner sealed off, the chain of custody clean, and the brand boundary enforced everywhere data crosses. Your clients see your name, never ours.

Updated · June 16, 2026Version 4Region · Singapore · ap-southeast-1

Become a partner Talk to security

Security contactFor vulnerability reports and procurement questions from your business owners, email help@larasx.com.

Larasengine roomPartneryour brand on topBusiness owneryour customerEnd customertheirs

PARTNER WORKSPACE MODEL

One partner. One workspace. One key boundary.

Every partner account is an isolated workspace. The business owners you serve, their conversations, connected accounts, and decision logs live inside your boundary. No partner can read, enumerate, or address another partner's data through any code path that ships.

01
Partner workspace scope
Each partner gets its own workspace id at signup. Every workspace-scoped query runs inside a binding that filters reads and writes to the calling partner. Cross-partner access requires a restricted operator context used only for support, audited per call.
02
Business owner sub-scope inside the partner
Inside your workspace, each business owner you serve sits in its own sub-scope. Catalog, customers, conversations, orders, payments, and brand voice are addressed by business owner. One staff session holds the view for one business owner at a time, never blended.
03
Per-workspace isolation as defense in depth
Postgres row-level security policies are layered on every workspace table. The application binds the partner identity on every query and the database enforces it on top. A runtime role switch that makes the database the primary gate is on the enterprise hardening roadmap, additive to the application-layer isolation already in production.

CONTROLS THAT RUN TODAY

The substrate. Every partner sits on this.

Stated as implemented. Where a control has a hardening dependency on the roadmap, the limit is named here rather than hidden as a marketing line.

Token encryption at rest: Connected platform credentials, OAuth tokens your business owners grant for messaging, commerce, and payments, are stored in encrypted columns using AES-256-GCM. Each row uses an independent random IV. The decryption key sits in a separate environment-variable boundary. Tokens are scoped to one workspace connection. No cross-partner reuse is possible.
Webhook signature verification: Inbound platform webhooks are verified before payload processing, each with the scheme that provider uses. Unverified requests are rejected. Processed events are deduplicated to guard against replay. Verification keys are scoped per partner per connection.
Pre-publish truth firewall: Replies that go out to your business owners pass a risk classifier before send. Regulated, medical, legal, financial, or brand-violation language holds the draft for owner review regardless of model confidence. The gate runs inside the partner workspace. Nothing leaves the boundary unscored.
Approval rules per business owner: Each business owner workspace declares the rules the work acts inside. Which actions auto-execute. Which need approval. Which always escalate. The runner acts inside the approved rules and escalates exceptions to the partner owner.
Evidence chain: Every action retains the input, the candidates considered, the gate decision, the model attribution, and the outcome at twenty-four hours. The chain is the audit trail your business owners' procurement teams can pull during review and your team can use to dispute, refund, or restore behavior.
SSRF guard on external fetch: Server-side fetches that consume client-supplied URLs validate the target against an allowlist that blocks private ranges, link local, cloud metadata services, and non-http(s) protocols. Redirects are walked manually with re-validation per hop.
Outbound rate enforcement: Platform-specific outbound caps are enforced pre-send via an atomic counter. End-customer opt-out keywords persist on the contact record and block further outbound across the partner workspace.
AI-assisted disclosure: Auto-sent replies append a compact AI-assisted disclosure footer. The disclosure is idempotent so operator-edited drafts that already disclose are not double marked. Footer wording follows the partner brand.
Transport and browser hardening: HSTS with a two-year preload, Content Security Policy, X-Frame-Options DENY, X-Content-Type-Options nosniff, Permissions Policy, and a strict Referrer Policy are set globally. TLS 1.3 by default at the edge.

BRAND BOUNDARIES

Your brand on the surface. The work underneath stays quiet.

Your brand on top is contractual, not a setting. The triangulation is explicit. The work runs under your brand. It serves your business owners. It talks to their end customers. The boundary between those three roles is enforced everywhere data crosses.

Surface: Dashboard, persona, voice, sender domains, status page. Business owners see the partner brand. End customers see the business owner brand. Nothing surfaces the Laras name on a business-owner-facing artifact.; PARTNER OWNS
Business owner data: Catalog, customers, conversations, orders, payments, brand voice. Lives in the partner workspace, sub-scoped per business owner. Export, archive, migrate, delete. All sit inside the partner boundary.; OWNER KEEPS
End customer data: Contact identifiers, conversation history, opt-out state. Stored against the business owner workspace. The partner cannot blend it with another business owner. Laras cannot blend it with another partner.; END CUSTOMER
Cross-partner movement: No code path moves business-owner data across partner workspaces. Cross-workspace pattern aggregation, if it runs, requires a minimum cohort gate to block re-identification and never carries raw business-owner content.; BLOCKED

COMPLIANCE POSTURE

Signals. Not certifications we have not earned.

GDPR alignment: End-customer data is processed under data minimization and lawful basis declared in the privacy policy. Data subject requests, access, deletion, portability, are routed through the partner. Sub-processor inventory is published. EU-bound traffic uses stateless inference where provider terms support it.
EU AI Act awareness: The work is treated as a high-stakes operator in business-owner-facing flows. Truth firewall, evidence chain, and human override are core mechanics, not add-ons. Risk classification on outputs is logged with model attribution per call.
TCPA and outbound discipline: Outbound messaging respects consent state per end customer, opt-out keywords are honored across channels, and outbound caps are enforced atomically. The partner workspace carries the audit trail your business owners need for outreach compliance reviews.
Subprocessor disclosure: A current named list of subprocessors, with legal entity, region, and contract posture, is published at /legal/subprocessors. New subprocessors land with notice through the partner agreement before they touch business-owner data.
Data residency: Application data resides in the Singapore region to align with ASEAN residency expectations. Partner agreements that require a different region are scoped through the enterprise track with the relevant data processing terms attached.
Inference statelessness: The model layer does not retain partner or business-owner prompts for training per contractual terms. Business-owner facts are read from your books at request time, not written to model weights. Pattern aggregation across partners, if performed, is gated by minimum cohort thresholds.

No SOC 2 stamp, no ISO certificate as of this writing. Enterprise business owners that need a stamp can scope it through the partner agreement. The mechanics above are real today.

RESPONSIBLE DISCLOSURE

How to report a vulnerability.

In scope

larasx.com domains and subdomains
Public hooks under /api/
Webhook receivers and OAuth callback flows
Partner workspace isolation, authentication, authorization bugs

Out of scope

Social engineering against staff, partners, or business owners
Physical security testing
Denial-of-service or load testing without prior coordination
Reports generated by automated scanners without verification

Reporting channel

Email help@larasx.com with technical detail and reproduction steps. PGP available on request.

Response SLA

Acknowledge within 48 hours. Critical issues fixed within 7 days. High within 30 days. Medium and below scheduled into the next release.

Safe harbor

Good-faith research under this policy will not lead to legal action. Coordinate before any testing that could impact platform availability or business-owner data.

Last updated June 16, 2026

NEXT STEP

Your brand on top. Laras underneath.

Launch the AI business under your name in a week, not a year.

Partner application takes a few minutes. The agreement, the workspace boundary, what your clients see, and the compliance posture get reviewed together. No sales call needed to read the mechanics.