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. Active only when LANTERN_CREDENTIAL_KEY is set — when unset, these columns are stored as plaintext pass-through, so set the key in any real deployment.
• HttpOnly JWT cookies -- dashboard auth tokens are issued server-side and never exposed to client-side JavaScript.
• Row-Level Security (RLS) policies on every tenant-scoped table (USING + WITH CHECK), guarded by a catalog gate-test — a new tenant table without RLS (or an explicit exemption) fails CI. Enforcement is staged per-environment via LANTERN_RLS_ENFORCE=1; the handler cutover is complete and make rls-validate proves the policies end-to-end against a live database.
• gRPC service-token auth on all three trust-boundary ports -- control-plane :50051, workflow-engine :50052, and runtime-scheduler :50055. Constant-time check, runs before tenant extraction, fail-closed in production.
• Runtime report binding -- step events and exit reports from a microVM are bound to that VM's own run: a report carrying another run's run_id is rejected with 403, so a compromised harness cannot spoof another tenant's audit or log stream.
• Ed25519-signed run receipts -- a SHA-256 of the run's full journal_events stream is signed (HMAC-SHA256 fallback when LANTERN_RECEIPT_ED25519_SEED is unset) and verifiable with no Lantern account at /proof and /.well-known/lantern-receipts.
• Per-endpoint API-key scopes -- mutating endpoints are annotated with required scopes (agents:write, runs:execute, …). Enforcement is flag-gated via LANTERN_AUTHZ_ENFORCE and default-OFF today; when off, missing scopes are logged, not rejected.
• Fail-closed token gates -- the gateway's API-key introspection endpoint and the personal /v1/signals endpoint both refuse (403/401) when their shared token env is unset, and validate with constant-time compares when set.
• 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

• Connector credentials and LLM provider API keys are AES-256-GCM encrypted at the application layer when LANTERN_CREDENTIAL_KEY is configured; when it is unset they are stored unencrypted (plaintext pass-through). Other Postgres columns use standard Postgres storage — disk-level encryption is the responsibility of the host.
• S3/MinIO objects (agent bundles, snapshots) use server-side encryption at the storage layer.

In transit

• All external traffic uses modern TLS — the gateway is built on rustls safe defaults (TLS 1.2 and 1.3)
• Internal gRPC traffic is authenticated with a pre-shared service token (LANTERN_GRPC_SERVICE_TOKEN) validated via constant-time compare — a UnaryServiceAuthInterceptor runs before tenant extraction, fail-closed in production. mTLS is the planned stronger follow-up and is not yet implemented.
• In-VM secret vending uses kernel-attested peer auth (SO_PEERCRED) on the Unix domain socket — only the expected workload uid may receive secrets, and the harness refuses any other peer at the kernel level.

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. The default backend is Kubernetes (RUNTIME_BACKEND=k8s); Docker is available for local development (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 -- syscall restriction is a property of the configured RuntimeClass (gVisor / Kata), not a Lantern-shipped profile
• Egress control -- an allowlist CONNECT proxy restricts outbound domains. Enforcement is fail-closed in production and requires the VM host/image to install the iptables REDIRECT rule; proxy env-var injection alone is advisory
• Resource limits -- CPU, memory, and disk are capped per run

Secret management

Secrets (API keys, OAuth tokens, credentials) are referenced via the lantern.secret/... form and resolved at execution time by the runtime secret resolver inside the sandbox; stored credentials are AES-256-GCM encrypted when LANTERN_CREDENTIAL_KEY is configured. Resolved values never appear in:

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