Security

Both AI models run directly on your resources. Your infrastructure data stays on your infrastructure. The only data that reaches our backend is billing metadata: a row per command with the resource name, agent type, command verb (run / scan / ask), GB processed, duration, and timestamp. Never the actual question, command output, logs, or metrics.

Local AI Execution

Each agent runs locally on your resource: TernaryPhysics-7B (Qwen2.5-7B quantized to Q4_K_M, ~4.7 GB) for conversational investigation, plus the TNN™ — a 2,888-parameter weight bank (not a generic neural network) used for mesh routing and packet authentication. Both run on CPU — no GPU required. Your infrastructure data never leaves the resource. Only billing metadata (resource name, agent type, command verb, GB, duration, timestamp) is sent to our servers.

How We Keep You Secure

Local AI Execution

  • Both AI models run on your resource
  • No GPU required — runs on CPU
  • TNN™ anomaly detector: sub-millisecond
  • TernaryPhysics-7B: real-time on CPU

Your Data Stays Local

  • Infrastructure data never leaves your resource
  • Only billing metadata leaves: resource name, agent type, command verb, GB, duration, timestamp
  • Credentials never leave your machine
  • Logs and metrics stay on-premise

Minimal External Dependency

  • Model downloads once per resource
  • No cloud AI APIs — fully local inference
  • No persistent connection required
  • Export audit logs to your SIEM

Human-in-the-Loop

  • Reads autonomously, writes require approval
  • Dangerous commands need explicit "yes"
  • All commands logged locally
  • You control what agents can access

Agent Security Model

Least Privilege Access

Agents request only the minimum permissions required for their function. A PostgreSQL agent only needs read access to system tables—it never requests write permissions unless explicitly enabled for remediation.

Approval Workflows

Any action that could modify your infrastructure requires explicit approval. Agents categorize commands as safe (read-only) or dangerous (mutations), and dangerous commands are blocked until you approve them.

Credential Handling

Credentials are read from your local environment variables or config files. They're never written to disk by our tools, never logged, and never transmitted anywhere.

Open Source Agents

Every agent's code is available for inspection. You can see exactly what commands an agent can run, what data it accesses, and how it processes information.

What We Never Do

  • ✕We never send your infrastructure data off-resource
  • ✕We never store or log your credentials
  • ✕We never use your data to train AI models
  • ✕We never execute write commands without your approval
  • ✕We never proxy your queries through cloud APIs

TNN Mesh™ Security

Every wire envelope between agents carries two independent signatures, both verified before the receiver acts on the message. They gate different things:

TNN signature — mesh membership

Every agent in a mesh derives the same TNN auth weights from a shared secret (Kubernetes Secret in production). The TNN signature proves the sender is in your mesh. Sub-millisecond, no PKI to manage. Patent Pending.

Ed25519 signature — sender identity

Each agent generates its own Ed25519 keypair on first start, persisted to ~/.local/share/tp-ops/identity/ at file mode 0600. The signature ties each message to a specific keypair, so a compromised pod can't impersonate a sibling. A trust-on-first-use peer registry catches "known agent name suddenly arrives with a different pubkey" — the canonical impersonation signal.

  • Mesh communication stays within your network — agents talk to each other directly, never through us
  • Optional TLS for confidentiality on the wire (set TP_OPS_MESH_TLS_CERT + TP_OPS_MESH_TLS_KEY); cert-manager / external CAs supported
  • Strict-identity mode (TP_OPS_MESH_REQUIRE_IDENTITY=1) rejects any envelope lacking the Ed25519 trailer — for production deployments where every peer must self-identify
  • Operator-pinned peer pubkeys for high-assurance bootstrapping (e.g. ConfigMap-provisioned)

TNN™ and TNN Mesh™ are Patent Pending technologies of TernaryPhysics LLC.

Vulnerability Reporting

Found a security issue? Please report it responsibly by emailing us directly.

ops@ternaryphysics.com