What BytePort can touch, what it can't, and how we prove it.

RBAC and least privilege

The agent runs as a dedicated Kubernetes ServiceAccount created in its own namespace (byteport-agent). Every action the agent can take is gated by a runbook-declared scope — a runbook must explicitly declare which Kubernetes resources it needs before those permissions are granted. If no runbook claims a resource, the agent has no access to it.

Kubernetes ClusterRole / Role — exact resource grants

Cloud IAM scopes — what we request per provider

What the agent does autonomously vs. what escalates

In auto mode, the agent acts without human approval only on the left column below. Everything in the right column triggers immediate escalation to your ops channel — the agent stops and waits. In the default dry_run mode, nothing in either column executes without explicit approval.

The classification logic is open source: github.com/Polsia-Inc/byteport-agent/src/runbooks. Read the code, not the marketing.

Audit log

Every agent decision — whether it acts, escalates, or does nothing — produces an immutable audit record. Records are written to the agent_actions table (in your BytePort account) and optionally streamed to your own storage.

Record schema

Sample JSON record

{
  "id": "01HXZ8K2P3Q4R5S6T7U8V9W0X1",
  "timestamp": "2026-05-30T06:14:22.341Z",
  "actor": "byteport-agent",
  "cluster": "prod-us-east-1",
  "signal_type": "disk_pressure",
  "signal_value": 91.5,
  "runbook": "DiskSpaceAutoReclaimRunbook",
  "decision": "acted",
  "command": "kubectl exec -n app node-3 -- docker system prune -f",
  "result": "success",
  "mttr_seconds": 187,
  "postmortem_url": "https://github.com/acme/ops/issues/214",
  "hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
}

Retention and export

Default retention: 90 days in the BytePort-managed store. Export is available to:

Export is available on Growth and Scale tiers. Configure via helm upgrade --set audit.export.target=s3.

Secrets handling

The agent never persists secrets. It reads credentials from the customer's secret manager at runtime, uses them for the duration of a single runbook execution, and discards them from memory when the runbook exits. No credential is written to disk, included in audit logs, or transmitted to the BytePort API.

Supported secret managers (pull-at-runtime):

Configure via BYTEPORT_SECRET_BACKEND=vault (or aws-sm, gcp-sm, k8s, doppler, 1password). Each backend is documented in /quickstart.

Data residency and processing

The agent runs inside your cluster. Most data never leaves. Here is the exact boundary:

Data processing

Signal metadata sent to the BytePort API is stored in Neon PostgreSQL hosted in AWS us-east-1. Data is encrypted at rest (AES-256) and in transit (TLS 1.3 minimum). Customer data is logically isolated — no cross-tenant data sharing. Retention: 90 days default; deletion on request within 72 hours.

Software supply chain

We treat the agent's build pipeline as a security surface.

Incident response

If you discover a security vulnerability in BytePort, please report it before disclosing publicly. We take coordinated disclosure seriously.

Coordinated disclosure policy

• Email security@byteport.polsia.app with a description of the vulnerability and steps to reproduce.
• We will confirm receipt within 24 hours and provide a triage assessment within 72 hours.
• We ask for a 90-day embargo from first contact to allow time to patch and notify affected customers. We will work with you on timeline if the vulnerability is actively exploited.
• We will credit you in the release notes if you want to be named (opt-in).
• We do not currently operate a bug bounty program, but we will consider it for high-impact disclosures.

Compliance posture

What is already in place:

Need security documentation for a procurement review? Email byteport@polsia.app — we can provide a completed security questionnaire and a scoped call with our team within 2 business days.