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

Only for anomalous patterns, and never in the steady state. Ordinarily 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. When a pattern trips anomaly detection, Auditty also sends a sample of the line that triggered it and some of its extracted values.

That exception is what allows an alert to tell you which request broke rather than only that something did. It is scoped to the pattern that tripped detection and never applies to the repetitive bulk of your logs.

If you would rather nothing but templates ever left your cluster, anomaly signals are a licensed capability and we will issue a licence without them, in which case the capability is not active in your deployment at all. 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.

Reading other containers' log files requires host-level access. 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, as compressed Parquet partitioned by time. 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.