Security and trust
Governed execution starts with a clear trust boundary.
NopsAI is designed for self-hosted operation, caller-scoped authorization, credential references, isolated runners and run-owned evidence — so teams can prove how AI-assisted work was allowed and executed.
Self-hosted
Control plane, state, credentials, runners and evidence stay inside your chosen environment.
Default deny
AAA evaluates route and runtime resource-use decisions before protected work proceeds.
Run-owned
Logs, authorization snapshots, approvals, outputs and final state stay attached to the run.
No public SOC 2
No SOC 2 report is currently published. Certification claims should wait for an issued report.
Trust boundary
Self-hosted control makes the boundary easier to reason about.
NopsAI separates entrypoints, control-plane decisions, data-plane execution and external provider calls, so evaluators can identify where data moves and which service owns each decision.
Entrypoints
Users, services, Git events and schedules
Browser, CLI, REST, GitHub App, managed Git webhooks, schedules and external triggers enter through authenticated or source-verified routes.
Control plane
API, AAA, config sync, dispatcher and persistence
The control plane authenticates callers, resolves GitOps definitions, checks AAA, records audit data and submits work to eligible runners.
Data plane
Docker and Kubernetes runners
Long-lived runners start per-run agents and isolated step containers or pods, then stream status and redacted logs back to the control plane.
Provider plane
Approved LLM, MCP and service endpoints
External systems are reached through explicit profiles, credential references and tool allowlists rather than arbitrary pipeline-defined servers.
Security controls
Controls that stay active during execution.
These are part of route composition, configuration resolution, dispatch, runner placement, provider access, monitoring and evidence capture — not a separate review step.
Caller-scoped AAA
Route authorization and runtime resource-use checks use default-deny, deny-before-allow decisions for the current subject.
GitOps configuration
Pipelines, steps, scopes, schedules, access manifests, LLM profiles, MCP registry files and runtime settings are reviewable in config repositories.
Credential references
Integration files store stable credential references. Values live in an encrypted, versioned registry or instance-encrypted GitOps envelopes.
Isolated execution
Runners create per-run agents and step containers or pods rather than executing sensitive work inside the UI or API process.
Approved MCP surfaces
Pipeline goals reference approved MCP profiles, while hosted MCP tools re-check AAA and audit concrete resource use.
Monitoring boundaries
System logs are authorized per source, redacted best effort, bounded in memory and separate from durable pipeline run logs.
Audit evidence and access
Proof is useful only when access to proof is governed too.
Run records, system logs, credential access logs and monitoring data are available through the same authenticated API and AAA boundaries used by the browser, CLI and hosted MCP surfaces.
Run evidence
Trigger source, requested and effective subjects, authorization snapshots, task state, logs, approvals, outputs and final status.
Audit records
AAA decision logs, credential consumer access logs, service-account activity and management events in the control-plane database.
Access boundaries
Evidence access follows product grants and low-level AAA checks; the CLI and browser both call the same protected API surface.
Operational telemetry
Prometheus metrics expose build identity, run health, log stream behavior, AI usage, reliability and runner signals without exposing secrets.
Compliance status
Clear status beats implied certification.
This page only claims compliance artifacts that exist. The focus is on product controls and evidence generation, not on presenting an unissued certification as complete.
SOC 2
No public report published
No SOC 2 Type I or Type II attestation is currently published. Treat NopsAI as not publicly SOC 2 attested until an issued report is available.
Data residency
Deployment-owned
Self-hosting keeps application state, credentials, runners, logs and generated evidence inside the environment you select.
Release integrity
Versioned bundle model
Release manifests, CLI/API/runner compatibility ranges, image digests, SBOM and provenance outputs and deployment locks support controlled production rollout.
Audit readiness
Evidence-generating by design
NopsAI records who started a run, what it did, where it ran, which profile it used, which resource checks passed and which outputs resulted.
Disclosure
Responsible disclosure
Report suspected vulnerabilities, exposed credentials, authorization bypasses or data-handling issues directly to the NopsAI security contact.
- We acknowledge security reports and request reproduction details when needed.
- We never ask reporters to disclose sensitive customer data publicly.
- We prioritize issues affecting authorization, credential handling, execution isolation or audit integrity.