Security Architecture
How signed tasks, scoped credentials, TLS, and access rules protect deployments
Warden starts outbound HTTPS connections to the LaserData control plane, the services that manage deployments. Signed tasks, signed binaries, and scoped credentials protect that management path. Application clients connect directly to deployment endpoints through TLS and access rules.
Security Model
Thick arrows show requests initiated by Warden. Dashed arrows show telemetry sent outbound from Warden. Apart from the data access proxy, which a deployment uses only while data access is on, the control plane does not initiate inbound connections to nodes.
Stream UI loads through the Console, then connects from the browser to Warden's HTTP proxy. Its short-lived Ed25519-signed session is limited to one deployment and user. Iggy payloads do not pass through the LaserData backend, unless data access through LaserData is on. Then Stream UI calls the Supervisor with a five-minute proxy token bound to one deployment, one user, and the Console session, and the Supervisor checks the live session and the member's permission on every request before it forwards the request once to Warden.
Stream UI is isolated from the surrounding Console. With data access off, an access rule must permit the browser IP, as for any other Iggy HTTP client.
Pull-Based Architecture
Warden starts every management connection from the node. The control plane supplies tasks through those outbound connections. It does not open an inbound connection to your infrastructure.
| Data Flow | Direction | Description |
|---|---|---|
| Config, tasks, certificates | Pulled by Warden | Warden polls the control plane over HTTPS |
| Heartbeats, metrics | Pushed by Warden | Warden reports node health outbound |
| Stream, topic, AGDX, and agent session metadata | Pushed by Warden | One node per deployment sends the changes of its Iggy metadata, its AGDX catalog and audit log, and the session summaries of its agentic streams, see below |
| Inbound management connections | None | Warden polls outbound. Client listeners are controlled separately |
This model has three requirements:
- Warden trusts authorized tasks from the control plane. Task-signing keys and control-plane identity remain security boundaries.
- Nodes need outbound HTTPS for management. Client traffic needs separate inbound access.
- Management requires no SSH keys, cloud-specific management agents, or bastion hosts.
Network Isolation
| Property | Managed | BYOC | On-Premise |
|---|---|---|---|
| Control plane can push commands | No | No | No |
| SSH access | None | None | None |
| SSM access | None | None | None |
| Inbound management connection from control plane | None | None | None |
| Message payloads leave infrastructure | N/A | Only while data access is on | No |
| Resource metadata sent to the control plane | Yes | Yes | Yes |
| LaserData has network access to endpoints | No | No | No |
Resource metadata is what the Console needs to list resources without connecting to a deployment: stream, topic, partition, and consumer group names, counts, options, sizes, and message counts, plus the change records of Iggy users and personal access tokens, with usernames, statuses, permissions, and token names and expiry. It also includes the current list of Iggy user ids and usernames, which deployment activity uses to name the user behind each change.
From the AGDX catalog it includes the names, descriptions, states, codecs, revisions, and digests of saved consumer filters, the consumer group that owns a group's own filter, and the consumer groups bound to them, the ids, names, versions, kinds, content types, and source topics of projections, the ids, parents, owners, statuses, and row counts of forks, and the numbers of destinations, schemas, and key-value namespaces and entries. From the managed backend's audit log it includes each record: for an applied change of a filter, filter binding, projection, schema, or fork, the ids, names, revisions, versions, and kinds the change names, the stream, topic, and consumer group of a binding, a fork's parent, the id of the Iggy user whose request was applied, and the time it was applied, and for the backend's other records, such as an accepted gap or a skipped record, the stream, topic, partition, and offset they name. Every audit log record is sealed with the deployment's catalog signing key, and Warden drops a record whose seal does not verify.
From the session index of every agentic stream it includes the session summaries that the agent session API serves, though no Console view lists them: the session id, the label and namespace cut to 255 characters, the agent, parent, and root, the status, the idle and over-budget flags, the start, end, event, and heartbeat times, the counts of events, model calls, tool calls, tokens, errors, and held records, the cost, the budget, and the SDK language and version.
It never includes message payloads, passwords, password hashes, token values, filter policies, projection definitions, schema bodies, key-value keys or values, table rows, or a session's tags, events, state, memory, or graph data. See metadata sync. Applied Iggy changes, retained AGDX role and binding events, and the AGDX changes in the audit log become deployment activity, which is never deleted, like the organization audit log. These entries carry identity and safe change details, with no secret. Metadata sync can be turned off per deployment, and the stored records deleted with it, through Update Metadata Sync.
Paid deployments need access rules before clients can connect. Managed Free deployments include a global rule. Application messages travel directly between clients and deployment nodes.
Encryption
| What | How |
|---|---|
| In transit | TLS on all connections - Warden to control plane, client to Iggy |
| NVMe SSD at rest | Encrypted at the hardware level by the cloud provider |
| Network disks at rest | Encryption always enabled (EBS on AWS, Persistent Disk on GCP) |
| Custom key encryption | Optional per-deployment encryption with a custom key on top of disk encryption |
| Certificate lifecycle | Automated issuance and rotation - no manual intervention |
| Audit data | Encrypted at rest, including actor names and event payloads |
Binary Integrity
Warden, Iggy, and Connectors binaries use cryptographic signatures. Before it executes a downloaded binary, Warden makes sure that its signature matches the LaserData public key. It rejects a binary with an invalid signature, including an unsigned replacement from a compromised download channel.
Task Signing
The control plane signs each operational task with Ed25519. Warden makes sure that the signature is valid before execution. This authenticates the task's origin and detects changes in transit.
Credential Scope
Warden Tokens
Each Warden agent uses an Ed25519-signed token limited to one node. This token grants management API permissions. It is separate from Iggy client credentials used to read or write application data. See Warden Agent.
Provisioning Credentials
BYOC Deployments
On AWS, LaserData assumes an IAM role for provisioning. The role grants these permissions:
| Permission Scope | Purpose |
|---|---|
| EC2 lifecycle | Provisioning and maintenance |
| Networking | VPC, subnets, security groups, NLB |
| EBS | Storage management |
It does not include S3, Secrets Manager, CloudWatch, or SSM.
On GCP, LaserData impersonates a service account with these permissions:
| Permission Scope | Purpose |
|---|---|
| Compute instances | Provisioning and maintenance |
| Networking | VPC, subnets, firewall rules, routes |
| IAM | Service account binding to instances |
It does not include Cloud Storage, Secret Manager, or Cloud Logging. Neither provider's provisioning permissions grant access to application data.
Managed Deployments
Managed nodes use minimal cloud credentials. Warden uses credentials created for the node during provisioning. Nodes do not receive broad cloud API access.
Multi-Cloud Consistency
Warden uses HTTPS on cloud instances or physical servers. The management model remains the same across providers. It does not depend on cloud-specific management agents.
Outgoing data-access relay
On-premise and private BYOC nodes can use Warden outgoing data access. The connection verifies the Supervisor hostname and certificate against the node's system trust store, like every other Warden request. Both Warden and the Supervisor enforce the deployment toggle, and a node-local setting that the Supervisor never writes can refuse the connection. Each forwarded request uses the existing signed deployment session and Console authorization.
Requests that arrive at another Supervisor instance use encrypted temporary relay buffers. Queued frames expire after 65 seconds. Infrastructure backup retention is separate from this transport expiry. A connection failure never triggers automatic replay of a write.