Skip to content
Nearzero
Star us

The Agent can see your infra. It cannot change production until you turn that on.

It reads deploys, logs, domains, and servers through scoped tools. Mutations need your role, administrator policy, and a production gate that starts off.

01

Observe, then act, then verify

The Agent can read projects, environments, services, deploys, logs, domains, servers, and Git metadata. It calls structured Nearzero tools and uses the returned result for the next step.

The Agent observes context, acts through a scoped tool, and verifies the returned result.
ObserveRead contextState, logs, policy
ActCall a scoped toolOnly when authorized
VerifyUse the resultNever invent success
02

The server enforces policy, not the model

Role checks and Agent action policies run in Nearzero. Production writes start disabled. An administrator has to turn that gate on.

BoundaryBehavior
Organization scopeTools operate within the active organization and the requesting user’s access.
Role and action policyEach protected action is checked server-side before infrastructure work begins.
Production environmentsAgent mutations are denied by default until an administrator enables them.
Tool resultsThe Agent must not claim success unless the invoked tool returns a successful result.
03

Do not paste secrets into chat

Do not paste API keys, tokens, passwords, private keys, or secret-bearing commands into Agent chat. Nearzero uses dedicated UI handoffs for service environment values and SSH setup so the model does not need the raw value.

  • 1
    Keep browser-exposed prefixes public.

    NEXT_PUBLIC_, PUBLIC_, and VITE_ values are intended for client bundles and must never contain credentials.

  • 2
    Treat database storage as privileged.

    API redaction is not encryption at rest. Encrypt volumes and backups, and restrict Postgres access.

  • 3
    Protect SSH material.

    Dedicated remote setup accounts have root-equivalent Docker and privilege access.

  • 4
    Rotate after suspected exposure.

    Redaction limits accidental display; it cannot revoke a credential that untrusted code already received.

04

Build secrets are not a sandbox

Generated build phases keep configured values out of ordinary command arguments and use BuildKit secret mounts where supported. Durable logs are redacted before storage. These controls reduce accidental leakage, but they cannot make untrusted build code safe.

  • Use the dedicated build-secret field when a Dockerfile needs a credential.
  • Keep non-sensitive build arguments separate from private runtime values.
  • Pin user-authored base images and production builder images by digest.
  • Rotate a credential after any suspicious or untrusted build.
05

Before you enable the Agent on production

  • ✓
    Roles match actual responsibilities.

    Only trusted operators can mutate production or deploy privileged Compose workloads.

  • ✓
    Model access is organization-scoped.

    Use the intended BYOK provider and rotate its key through the settings flow.

  • ✓
    Production mutations remain off until needed.

    Enable them only after backups, rollback, and observability are tested.

  • ✓
    Secrets stay out of chat and public prefixes.

    Use the secure configuration surfaces and inspect client bundles before release.

  • ✓
    Every action is verified.

    Check deployment state, logs, domain resolution, and runtime health after changes.

Questions this page answers

Can the Nearzero Agent change production without permission?

No. It can inspect project state and logs, but it can only mutate what the requesting user's RBAC and workspace policy allow. Production writes stay disabled until an administrator turns that gate on.

Does the Agent get unrestricted SSH or Docker access?

No. It uses scoped Nearzero tools through the control-plane API. It cannot invent privileged paths or bypass administrator policy.