Security posture

Read-only is enforced by RBAC, not by promise.

ifa is solo-built, pre-users alpha software. It is built for teams that are rightly cautious about anything touching production inference — this page states the access model plainly rather than asserting trust.

RBAC permissions, in full

The default installs a namespaced Role, not a cluster-wide grant. The chart escalates to a ClusterRole only when explicitly configured to watch every namespace. There are exactly three resources, all read verbs, no exceptions.

Resource	Verbs	Why
deployments	get, list, watch	Replica counts, which the scaling rules need and which no inference runtime knows about.
pods	get, list, watch	Container restart counts, which separate slow to start from crash-looping when replicas are unavailable.
horizontalpodautoscalers	get, list, watch	The replica ceiling, which distinguishes queueing, and the autoscaler will fix it from queueing at the ceiling, and nothing will.

role.yaml — the default; no create / update / patch / delete

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ifa
  namespace: inference
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["autoscaling"]
    resources: ["horizontalpodautoscalers"]
    verbs: ["get", "list", "watch"]

Watching every namespace requires opting into a ClusterRole with the same three resources and the same read-only verbs — no additional permissions are added at that scope. There is no write verb anywhere in the chart: no create, update, patch, or delete.

What is not collected

Prompts

Request bodies

Model outputs

Training data

Secrets or credentials

User conversations

Air-gapped operation

There is no "air-gapped mode" flag. Air-gapped operation is a property of the deployment — no egress, mirrored images, a NetworkPolicy — not a runtime setting. A configuration field that claimed to enforce it while enforcing nothing would be security theatre.

ifa communicates only with the endpoints it is configured to use: the inference metrics endpoints it scrapes, DCGM exporters, and the Kubernetes API. It can additionally deliver webhook alerts when you explicitly configure a destination: IFA_ALERTING_WEBHOOK_URL sets it and can remain unset in air-gapped deployments. That is configured collection traffic, Kubernetes API access, and optional delivery — not phone-home. ifa performs no licence check, no usage telemetry, no update check, and no crash reporting. The only things that need to cross the boundary are the container image and the Helm chart. scripts/package-offline.sh mirrors both for transfer, and docs/DEPLOYMENT.md documents the full procedure.

Access model

Read-only by default — no create, update, patch, or delete permissions on any resource.
Least-privilege Kubernetes RBAC requesting only the verbs listed below.
Scoped namespace deployment; nothing outside the chosen scope is observed.
No agent is inserted into the inference request path.

Data handling

No prompts, request bodies, or model outputs are collected by default.
Only operational telemetry — latency, queue depth, KV cache, GPU signals — is ingested from Prometheus.
Telemetry is stored in-memory; TimescaleDB is an optional additional historical sink when configured. Dynamic multi-scrape evaluation is integration-tested in Kubernetes. A real TimescaleDB database integration test remains outstanding.
Data scope and retention are configurable per deployment.

Deployment and lifecycle

Installed via a Helm chart and driven from the ifa CLI.
A NetworkPolicy template is included to constrain the control plane's networking in your cluster.
Supports air-gapped deployment via a documented image and chart mirroring script.
Uninstall by removing the Helm release and its RBAC objects; no controllers are left behind.

Current stage

ifa is solo-built and pre-users. An alpha release, v0.2.0-alpha.1, is published — the container image is public and a default helm install resolves. That makes the stage datable, not further along: it is intended for evaluation in development, staging, or scoped production-like environments. Production deployment should be reviewed with your own infrastructure and security team before use.

Have a specific security requirement or review process? Reach out at security@p95labs.com.