Security

• Source access should follow the permissions of the connected system.
• Workspace data should stay isolated by account, tenant, and workspace boundary.
• Source-backed answers should include evidence where possible.
• Consequential external actions should stay behind user approval.
• Failures should be visible and recoverable instead of hidden.

ELAV connects to business systems through authorized provider flows such as OAuth or customer-approved import paths. Disconnecting a source should stop ELAV from using that source for new source-backed answers.

ELAV is designed as a tenant-scoped product. Product records, source artifacts, memory, approvals, and operations are expected to include a tenant boundary so one workspace cannot read another workspace's data.

ELAV should not turn weak evidence into confident claims. When an answer depends on connected work context, the product is designed to show the source evidence used where possible and call out missing or withheld context.

ELAV may prepare drafts, briefs, reminders, and proposed next steps. The default product principle is that consequential external actions, such as sending messages or changing external systems, require user approval.

ELAV routes model work through a controlled LLM layer rather than allowing features to call model providers directly. Retrieved context may be sent to AI providers to produce answers, summaries, memory candidates, or drafts. Customer source content is not used to train generalized AI models unless explicitly agreed in writing.

• Data processing addendum available during procurement.
• Subprocessor details available during procurement.
• Custom retention, SSO, dedicated hosting, and enterprise controls can be scoped for Company or Enterprise deployments.
• Security questionnaires can be sent to the ELAV team for review.