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.
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.
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, knowledge documents, wiki connections, 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.
Bound guardrails and policies
A pipeline, step or task declares which reviewed documents constrain it. Guardrails and policies are evaluated against the goal, the generated command, direct scripts, file writes and MCP arguments, and the resolved text is snapshotted on the run.
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.
The questions that decide a sign-off.
Answered here rather than in a call, including the one where the honest answer is a caveat. The full topology is on the architecture page.
Where do credentials live?
Encrypted in the control plane. Decryption happens only in the control-plane service — no runner, dispatcher or agent holds a decryption key. An agent receives resolved values for the run it is executing, and those values are masked in stored logs.
When are secrets resolved?
Before dispatch. Configuration in Git stores stable credential references rather than values, so a config repository never contains a secret, and a reviewer can read the whole configuration surface without being exposed to one.
What is the agent allowed to do?
Only what its pipeline declared. Agent, LLM and MCP profiles are selected by name from approved definitions rather than assembled at runtime by a task, so a compromised prompt cannot widen the tool surface it was given. The guardrails and policies bound to that pipeline, step or task narrow it further, and are checked against the concrete action before it executes.
What authorizes a run?
A separate authorization service, called over an internal-token-protected interface, resolves the caller and answers check, batch-check and filter questions. The effective subject is recorded on the run record and on AI usage events.
What can the agent reach on Kubernetes?
The agent pod runs in its namespace under a dedicated workload service account, drops all Linux capabilities, disables privilege escalation and runs under the runtime default seccomp profile. Its reach is exactly what that service account's RBAC permits.
What can the agent reach on Docker?
More. The Docker runner binds the host Docker socket into the agent container so the agent can create step containers, which means an agent on that host can do what the Docker daemon can do. Use the Kubernetes runner for production, and treat a Docker runner host as a dedicated job host.
What can a step container reach?
The narrowest scope in the system. Steps run with new privileges disabled, a process limit and an init process, mounting the run workspace as a named volume. Step containers are never given the Docker socket.
Does the API hold the Docker socket?
No. Container visibility for system logs goes through a dedicated proxy that permits only GET requests for ping, version, container list and inspect or logs on allow-listed platform containers. Mutations, events, stats and archive endpoints are rejected outright.
What survives a run?
The run record: trigger source, effective subject, authorization outcome, the resolved knowledge that bounded each decision, task history, tool calls, approval decisions and approvers, AI usage and declared outputs. Workspace volumes are removed when the agent finishes; anything that must persist is an explicit output or a checkpoint.
Which model sees our data?
The one you configured, under your own account. NopsAI ships no model and hosts no inference endpoint: an LLM profile names a provider, a model and a credential reference that resolves to your key. Prompts and completions travel from your agent container to your provider, and the contract covering how that provider treats them is yours, not ours.
Who is the provider under the EU AI Act?
Usually you. We supply orchestration software with no model in it; the AI system that gets placed into service is the combination you assemble from your model, your tools and your pipelines, and the organization that does that assembling and puts it to use carries the provider or deployer obligations. Where the answer matters to your risk classification, get it confirmed in writing rather than inferred from this page.
What happens when a control fails?
Under the default governance level, strict, a policy or guardrail review that returns anything other than a clear allow stops the run — violation, conflict, uncertainty or an unsupported decision alike. An advisory level exists for teams that want the judgment recorded without gating on it, but advisory never skips the evaluation: where no judgment can be obtained at all, because no model resolves or the review call fails, the task fails closed at every level.
Related: system architecture, governance and access and runtime and execution.
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.
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.
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.