Security
The engine runs in your infrastructure and log content never reaches log10x. What a deployed engine does send about itself, and how to prove it with a packet capture, is the security reference; the answers below cover the questions a review asks around it.
-
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.
-
How the agent authenticates, how keys are issued and rotated, vulnerability handling, security review, internal access, and analytics-tool credentials.
-
Supported clouds, EU regions, tenant isolation, network access, and on-premises / air-gapped.
-
Product shape, outbound calls and how to falsify them, the telemetry schema, and per-release SBOMs.
-
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 account API key sent in the X-10X-Auth header, never a shared master key. It carries a permission level (OWNER, WRITE, READ) resolved per environment, so an agent can be given read on production and write on staging. The key is long-lived, and you can rotate it at any time, which invalidates the old key immediately. The API key and the engine license are separate credentials: the key authenticates the control surface, the license is what the engine verifies offline to run. The install wizard can mint a license through your own signed-in session and place it in the Helm plan it emits, which is the one point where the agent handles it. 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 events the Retriever offloaded, 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.