Security

Lantern is designed for production workloads that handle sensitive data. Security is not an add-on -- it is built into every layer of the architecture, from the microVM runtime to the model router.

What is shipped today

• AES-256-GCM encryption at rest for connector credentials and LLM provider keys (LANTERN_CREDENTIAL_KEY).
• HttpOnly JWT cookies -- dashboard auth tokens are issued server-side and never exposed to client-side JavaScript.
• Row-Level Security (RLS) policies on all 34 tenant tables (USING + WITH CHECK). Enforcement is staged: policies are installed and tested, and will be activated per-environment via LANTERN_RLS_ENFORCE=1 as handler cutovers complete.
• gRPC service-token auth on :50051 -- constant-time check, runs before tenant extraction, fail-closed in production.
• A2A tenant isolation -- GetAgentCard / InvokeAgent gate on is_public OR caller-tenant; private agents return 404 to cross-tenant callers.
• Bridge retry + surface-gateway tenant resolution -- the surface gateway resolves a real Lantern LANTERN_TENANT_ID instead of using platform IDs; unknown installs are rejected.
• LLM idempotency keys on all provider calls -- derived from (run_id, step_id, attempt), reused across same-provider retries.
• Dependency vuln gate -- govulncheck, cargo-audit, and npm audit run on every CI build.
• OTel traces with tenant_id -- every HTTP request and gRPC call carries a span enriched with tenant_id, run_id, and step_id.

Privacy levels (planned)

The following privacy levels are part of the architecture design and are not yet implemented. They are documented here for reference.

• Standard -- default level. Data is encrypted at rest and in transit. Logs include input/output for debugging. Suitable for most use cases.
• Strict (planned) -- inputs and outputs are not logged. PII is automatically detected and redacted in traces. Audit log entries are created for all data access.
• Paranoid (planned) -- end-to-end encryption. Data is encrypted before leaving the client and decrypted only inside the microVM. The control plane never sees plaintext data. Designed for healthcare, finance, and legal use cases.

Guardrails (partial)

Guardrails are rules that constrain what an agent can do. They are enforced at the runtime level, not by the LLM -- so they cannot be bypassed by prompt injection.

Built-in guardrails

• Output validation -- verify that agent outputs conform to a schema before delivery
• Domain restrictions -- limit which external URLs the agent can access
• Token limits -- cap the maximum tokens per step and per run
• Cost limits -- set a maximum dollar amount per run to prevent runaway costs
• Human-in-the-loop -- require human approval before executing certain actions (sending emails, creating issues, etc.)

Configuring guardrails

Guardrails are configured in the agent's Security tab:

{
  "guardrails": {
    "max_tokens_per_step": 4096,
    "max_cost_per_run": 1.00,
    "allowed_domains": ["*.github.com", "*.google.com"],
    "require_approval": ["gmail.send", "github.createIssue"],
    "block_pii": true
  }
}

PII blocking (planned)

When block_pii is enabled, Lantern automatically detects and redacts personally identifiable information in agent inputs and outputs:

• Email addresses
• Phone numbers
• Social Security numbers
• Credit card numbers
• Physical addresses
• IP addresses

PII detection runs inside the microVM before data is logged or stored. Redacted values are replaced with tokens like [EMAIL_REDACTED] in logs and traces.

Data encryption

At rest

• All data in Postgres is encrypted using AES-256
• Secrets and API keys use envelope encryption with tenant-specific keys
• S3 objects use server-side encryption (SSE-S3 or SSE-KMS)

In transit

• All external traffic uses TLS 1.3
• Internal gRPC traffic between control plane and data plane uses mutual TLS (mTLS)
• The "paranoid" privacy level adds end-to-end encryption on top of TLS

Bring your own key (BYOK) (planned)

Enterprise customers will be able to provide their own encryption keys via AWS KMS, Google Cloud KMS, or Azure Key Vault. This feature is on the roadmap and not yet available.

Audit logging (partial)

Run-level events are recorded in journal_events (the run event journal). A full immutable audit log covering secret access, role changes, and dashboard actions is on the roadmap. The following are tracked today:

• Run start, completion, and failure (via journal_events)
• A2A agent card access (tenant-scoped, cross-tenant denials logged)

SIEM export via webhook or S3 is planned but not yet available.

Isolation

Agent runs execute inside isolated sandboxes. The isolation class depends on the workload type. In local development, Docker containers are the default backend (RUNTIME_BACKEND=docker). In production, the runtime-manager supports gVisor (standard), Kata microVM (hostile), and Firecracker-backed Kata for the highest isolation tier. Fail-closed: untrusted/hostile workloads are refused unless the appropriate RuntimeClass is configured -- never silently downgraded to a bare pod.

All isolation tiers provide:

• Process isolation -- each run has its own kernel, filesystem, and network namespace
• seccomp filtering -- only allowed syscalls can execute
• Egress control -- network access is restricted to explicitly allowed domains
• Resource limits -- CPU, memory, and disk are capped per run

Secret management

Secrets (API keys, OAuth tokens, credentials) are never stored in plaintext. Lantern uses the lantern.secret/... reference form throughout the system. Secrets are resolved at execution time inside the microVM, and never appear in:

• Logs or traces
• Run state or step outputs
• Dashboard UI
• API responses