Your archive stays in your account. We hold no key to it.

No. What leaves your cluster is log templates, the shape of a line with all values masked to placeholders, plus counts, rates, timing and node, namespace and workload names. A template records that a line of a given shape occurred, not what was in it, and cannot reconstruct the original.

This holds for anomalies too. When a pattern is seen for the first time or its rate spikes, what reaches us is the template and the rates, which is enough to alert you and to identify the pattern. It is not a sample of your logs.

Reading the lines themselves is a request you make: a retrieval is served out of your own bucket, by a component running in your own account, returning only the rows you asked for. Everything forwarded to your own SIEM or log vendor goes there directly and never passes through Auditty either way.

No. Auditty's control plane holds no credentials for your object storage and has no network path to it. The archive is written by your own agent, running inside your own account, using credentials you issue and can revoke without involving Auditty.

When the control plane needs archived data because you requested a retrieval, it asks a service running inside your cluster, which reads from your bucket locally and returns only the rows matching your request. There is no cross-account role to grant and no vendor access to review.

No. It runs with two scoped Linux capabilities, DAC_READ_SEARCH and SYS_PTRACE, rather than in privileged mode. Reading other containers’ log files does require host-level access, and those two capabilities are the whole of what that takes.

Concretely, the agent needs read and write access to the node's pod log directory, so that it can read the raw stream and write the filtered one back to the path your log shipper already watches, and read-only access to process information on the host, so that it acts on log files that are genuinely in use.

Auditty does not exec into containers, read application memory, modify workloads, or touch logs for pods outside the rules you wrote. Recovery of a damaged or deleted log file is scoped to pods matching an interception rule, so a log Auditty was not asked to handle is left alone even when it is visibly broken.

Your log data is stored in your own Amazon S3, Google Cloud Storage or Azure Blob Storage bucket, under a prefix you choose, compressed and partitioned by time in an open format your own tools can read. Auditty never holds a copy.

Retention is whatever your own bucket lifecycle policy says, because it is your storage and your billing relationship. Auditty applies no retention limit and takes no storage margin.

Your logs keep flowing. Restoring your log pipeline is the very first thing Auditty does on the way out, ahead of any of its own cleanup, so the file your log shipper watches is working again within milliseconds, before the process has finished exiting. After an abrupt kill or a node reboot there is nothing to repair by hand either: the same restoration happens automatically, in milliseconds, and removing Auditty entirely leaves your logging exactly as it was before you installed it.

If the connection to the control plane fails, nodes continue running the last rule set they successfully validated; an empty rule set is never synthesised from a failure. If your object storage becomes unreachable, suppression stops automatically, so events are forwarded rather than summarised into an archive that is not accepting writes. You get a larger bill rather than a gap in your data.

No. Auditty entitlements are cryptographically signed tokens verified locally on the node, so there is no phone-home licence check that can disable your log pipeline when Auditty's service has an outage.

Nodes that lose contact with the control plane continue processing with their last validated rule set and keep writing to your object storage. Loss of the control plane costs you visibility and rule changes, not log processing.