Security
Zero-data-egress security architecture. All log processing happens in your infrastructure. Logs never leave your network.
-
Where processing happens, what data leaves your network, symbol libraries, AI, and validating that security logs aren't filtered.
-
Encryption, SOC 2, GDPR, HIPAA, SOX/PCI-DSS, metric retention, and incident response.
-
Auth (SaaS / on-prem / air-gapped), vulnerability handling, security review, internal access, compiler, and analytics-tool credentials.
-
Supported clouds, EU regions, tenant isolation, network access, and on-premises / air-gapped.
-
What the AI agent can do in your pipeline, the credential it uses, what it sees, where changes land, and how to run it read-only.
Agent operation
10x is operated by an AI agent (Claude or any agent) through the log10x MCP server. Here is exactly what the agent can do inside your pipeline, and the control a security reviewer can check for each claim.
What credential does the agent use?
A scoped, rotatable, per-environment API key sent in the X-10X-Auth header, never a shared master key. The key is long-lived, and you can rotate it at any time, which invalidates the old key immediately. The agent never holds your engine license credential. In self-managed deployments it uses your own metrics backend and your own repository credentials with the scope you grant.
What does the agent see?
The agent reads pre-aggregated, per-pattern metrics (event counts, byte volumes, cost per pattern). It does not stream raw events to log10x. When you ask it to inspect a specific pattern, it retrieves sample lines from a source you control, your SIEM or the Retriever archive, using your own credentials; those samples reach only the agent you run and are never sent to log10x. Raw log content is fingerprinted and compacted locally by the engine inside your infrastructure.
Where do proposed changes land?
The agent proposes a config change as a diff (a cap CSV plus an action-intent record) to a destination you control: a pull request in your own GitOps repository that your reviewers merge, a ConfigMap on your cluster, or stdout for inspection. The engine, not the agent, enforces the change, and a cap is a ceiling the engine applies. The agent cannot exceed it or drop live logs directly. Choose the GitOps path when you want a human merge gate before any change takes effect.
How do I evaluate it safely?
Set LOG10X_MCP_READ_ONLY=true to block all writes while keeping the agent usable for planning, or deliver changes to stdout only so you can inspect every diff before it lands.
Is there an audit trail?
Every proposed and applied action is recorded with a stable pattern identity, the reason, and a timestamp, in history you own. Because the record lives in your GitOps repository or config store, it doubles as change-management evidence for your own audit controls.