Security at Lieva

Lieva is an Agent Flight Recorder. It records the trace of an AI agent run and helps you repair the broken or expensive step. The most important security property of Lieva is where the sensitive work happens: in your environment, not ours.

Forks and replays run locally. When you fork from step N and re-run the downstream of a trace with your fix, that execution uses your runtime, your network, and your credentials. The replay calls your LLM provider directly from your environment.

Because of this, your provider API keys never leave your machine or environment. They are not transmitted to Lieva, not proxied through Lieva, and not stored by Lieva. We do not need them, so we do not ask for them and we do not hold them.

Lieva works on the trace data you choose to send. A trace can include model calls, tool calls, state transitions, retries, token usage, cost, latency, retrieved chunks, and failures. Depending on what you capture, that data may contain prompts, completions, tool inputs and outputs, and related metadata.

You control what is captured and what is sent. The SDK and import path are opt-in by event type, and you can drop or transform fields before they reach us. Because you decide the payload, you are responsible for not sending data you are not permitted to share with a third-party processor.

We treat trace contents as your data. We do not sell it, and we do not use the contents of your traces to train models for other customers.

The most reliable way to keep sensitive material out of Lieva is to never send it. Lieva gives you controls to redact or strip fields at the source, before the trace leaves your environment, so secrets and regulated data are removed at capture time rather than after the fact.

Redaction runs in your runtime as part of the SDK or import step. Because it runs before transmission, a field you redact at the source is never in transit to Lieva and never written to Lieva storage.

Trace data is encrypted in transit and at rest. In transit, Lieva requires TLS 1.2 or higher for connections to its APIs and web application and rejects plaintext connections. At rest, stored trace data and backups are encrypted using industry-standard algorithms managed by our cloud provider.

Encryption protects data while we hold it, but the strongest protection remains the local-first model above: data you redact at the source, and keys that never leave your environment, are never exposed to Lieva in the first place.

Lieva is multi-tenant. Every trace, run, eval, and project is scoped to an organization, and authorization is checked server-side on every request. The system is designed so that one customer cannot read or act on another customer's data, with access keyed to the authenticated organization rather than inferred from the client.

Inside Lieva, access to production systems and customer data follows least privilege. Access is limited to the people who need it to operate and support the product, granted by role rather than broadly, and reviewed and revoked as roles change.

Lieva does not store your LLM provider keys, because replays run in your environment and call providers directly from there. The credentials Lieva does manage are its own: API tokens you issue to authenticate the SDK, and internal service credentials.

Customer-facing API tokens are scoped to an organization and can be rotated or revoked at any time. Internal secrets and service credentials are stored in a dedicated secrets manager, kept out of source control, and injected at runtime rather than hard-coded. If you believe a Lieva API token has been exposed, rotate it immediately and tell us at security@uselieva.com.

Lieva runs on a major cloud provider whose platform carries widely recognized security and compliance attestations for the underlying infrastructure. Those attestations cover the provider's base layer, not Lieva's own application; we build on managed services so that hardening, patching, and physical security of the base layer are handled by the provider, and we focus our own controls on the application and data layers.

Network access to production is restricted, administrative access requires authentication, and infrastructure changes go through review rather than ad hoc manual edits.

We log application and infrastructure activity to detect errors, abuse, and anomalous behavior, and we retain audit-relevant events so we can investigate and respond when something looks wrong.

We aim to keep sensitive trace contents out of operational logs. Those logs are oriented around request metadata, system health, and access events rather than the bodies of your prompts and completions. Redacting sensitive fields at the source further reduces the chance that anything sensitive lands in any log.

We track vulnerabilities in our own code and in the third-party dependencies we ship. Dependencies are scanned for known advisories, and we prioritize and apply security patches based on severity and exploitability.

We prefer automated, continuous checks over one-off audits so that a newly disclosed CVE in a dependency surfaces quickly rather than at the next manual review.

Trace data is backed up so it can be recovered after operational failure, and backups are encrypted at rest like primary storage. The goal is straightforward recovery of customer data after an incident without weakening the protections that apply to the live data.

Backups inherit the same access controls and tenant scoping as production. They are not a side channel for broader access.

Lieva is an early-stage, US-incorporated company, and we describe our compliance posture honestly. SOC 2 is on our roadmap and in progress. We are not claiming that Lieva is currently SOC 2 certified or audited, and you should not treat anything on this page as a certification.

As formal attestations are completed, we will state clearly what was assessed, by whom, and over what period, rather than implying coverage we do not have. If your procurement process needs current documentation, email security@uselieva.com and we will share what we can.

This page is informational and describes our practices in good faith. It is not legal advice and is not a substitute for your own security and legal review of whether sending a given trace to a third-party processor is appropriate for your organization.

If you find a security issue in Lieva, we want to hear about it. Email security@uselieva.com with enough detail to reproduce: affected endpoint or component, steps, impact, and any proof-of-concept. We will acknowledge your report, investigate, and keep you updated on remediation.

Please report privately and give us a reasonable chance to fix the issue before any public disclosure. Avoid accessing or modifying other customers' data, degrading the service, or running automated scans that could affect availability. We will not pursue action against good-faith research that respects these boundaries.