Security

Each hop between the caller, the control plane, the data-plane host and the microVM is a trust boundary with its own credential, and untrusted code sits behind all of them.

A tool call reaches code in a microVM with no network card. Over vsock it reaches the host broker, which applies the allowlist and adds the key; keys stay on the host. An allowed host goes through, any other host is refused and audited.

How a sandbox reaches the network, and why it never holds a credential in broker mode: Egress and credentials.

This page answers three questions.

Can one customer’s agent see another customer’s data? No. Every record is fenced by tenant, enforced down to the database row.
What happens if an agent runs malicious code? It runs inside a microVM, with egress limited to a per-sandbox allowlist: structurally in broker mode, where the VM has no network device, and in default mode when the image installs the iptables REDIRECT rule.
Can you prove what an agent did? Yes. You can issue a signed receipt for any completed run; with an Ed25519 seed configured, anyone can verify it.

Everything below is labeled shipped or planned.

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 session cookie. Dashboard auth uses an HttpOnly session cookie; the JWT is also kept in localStorage for client-side API calls.
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.
Per-endpoint API-key scopes. Mutating endpoints are annotated with required scopes (agents:write, runs:execute, and so on). Enforcement is flag-gated via LANTERN_AUTHZ_ENFORCE and defaults to off; when off, missing scopes are logged, not rejected. Production enforces them (LANTERN_AUTHZ_ENFORCE=1 in the Helm prod values): a key missing the endpoint’s scope gets 403. Dashboard/owner JWT sessions and unscoped legacy keys keep full access.
gRPC service-token auth on every internal gRPC port: control plane :50051, workflow engine :50052, model router :50053, runtime manager :50054 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.
Signed run receipts. Issued on request for a completed run (POST /v1/runs/{id}/receipt). A SHA-256 of the run’s full journal_events stream is signed with Ed25519 when LANTERN_RECEIPT_ED25519_SEED is set (verifiable with no PAL account at /proof against the key at /.well-known/lantern-receipts), with an HMAC-SHA256 dev fallback otherwise (verifiable only by the deployment).
Fail-closed token gate. The gateway’s API-key introspection endpoint refuses (403) in production when LANTERN_GRPC_SERVICE_TOKEN is unset (dev allows it with a warning). Token comparisons are constant-time when set.
A2A tenant isolation. GetAgentCard / InvokeAgent gate on is_public OR caller tenant; private agents return 404 to cross-tenant callers.
Bridge retry and surface-gateway tenant resolution. The surface gateway resolves a real 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) and reused across same-provider retries.
Dependency vulnerability gate. govulncheck, cargo-audit, and npm audit run on every CI build.
OTel traces with tenant_id. Every control-plane 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. The 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.

Privacy levels can be set per agent and per connector once the feature ships.

Runtime controls

These constraints are enforced by the platform, outside the model, so a prompt injection cannot talk its way past them.

Budgets. Per-agent caps on cost per day and runs per day, and a tenant-wide daily cost cap. A hard-fail budget returns HTTP 402 before the run starts. Tokens/day is enforced at the same gates. The per-run cap is enforced mid-run in workflows and reported after the fact elsewhere; per-tool limits apply to workflow tool and connector nodes. Hard-fail budgets fail closed (503 on run create) when the budget cannot be read.
Egress allowlist. Declared per spawn. In broker mode anything not on the allowlist is denied structurally (there is no network device). In default mode the allowlist binds only when the VM host/image installs the iptables REDIRECT rule. See Egress and credentials.
Human approval. Workflow approval nodes block on a takeover request until an operator grants it. Nested approvals inside child runs fail today rather than wait.
Confidence gate. Low-confidence tool and connector steps divert to approval. Off by default (LANTERN_CONFIDENCE_GATE).

A run request meets the budget check (forecast and daily caps). Over the cap it is refused with 402, no model call, costing nothing. Under the cap it is routed by capability and the usage is recorded.

PII redaction (planned)

Automatic PII detection and redaction in agent inputs, outputs and traces is not implemented. Do not rely on it.

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): encryption is a bucket setting you configure on your storage. PAL does not set it.

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.
Default egress mode: 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 requests return 404).

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 or hostile workloads are refused unless the appropriate RuntimeClass is configured, and are never silently downgraded to a bare pod.

All isolation tiers provide:

Process isolation. Separate filesystem and network namespace per run; microVM classes add their own guest kernel.
seccomp filtering. Syscall restriction is a property of the configured RuntimeClass (gVisor / Kata), not a PAL-shipped profile.
Egress control. Default mode: an in-guest allowlist CONNECT proxy, fail-closed in production, which needs the iptables REDIRECT rule on the VM host/image (proxy env vars alone are advisory). Opt-in broker mode (LANTERN_EGRESS_MODE=broker, Firecracker only): the VM has no network device and a host broker enforces the allowlist and injects credentials, so they never enter the VM.
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 manager’s secret resolver (via the control-plane relay). 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