Concepts

Overview

NebGuard is a safety layer that sits between an AI coding agent and the actions it takes. It carries its rule library inside the binary, evaluates each action locally, and never needs a network call to make a decision. This page covers the model it works by: the four responses, the fail-safe posture, the rule domains, how licensing maps to those domains, and how telemetry and air-gapped operation work.

The four responses

Every action an agent is about to take, and key moments such as finishing a turn, gets one of four responses:

• Allow: the action is fine and proceeds untouched.
• Warn: the action is risky, so NebGuard attaches a note for the agent and the human to reconsider.
• Block: the action is dangerous, so NebGuard stops it before it runs.
• Guide: NebGuard injects context to keep the agent on course, and re-states key constraints after the agent trims its own context, so the rules survive the agent's memory management.

Only the check that runs before a tool executes can actually block. The others observe, warn, guide, or record.

Fail-safe and no self-bypass

Two guarantees keep the guardrails trustworthy even when something goes wrong:

• No self-bypass. When a rule blocks a genuinely dangerous action, the agent cannot disable that guard by writing its own justification. That class of guard is bypass-proof by design. Lower-stakes warnings may still carry an explicit human override.
• Fail closed where it counts. If a high-stakes guard's own check errors out, it becomes a block rather than silently letting the action through. Observational and warning rules do the opposite: they fail open, so a glitch in a non-critical rule never wrongly blocks a legitimate action. The cost of being wrong decides the direction of failure.

The seven rule domains

Rules are grouped into seven domains:

security, infrastructure, development, operations, ai-governance, business, global.

Whether a given domain is active depends on two independent things: your license tier (what you are entitled to) and your environment (whether the rule even applies to where you are running). A rule fires only when both checks pass.

Licensing tiers

NebGuard's licensing answers one question: how many of the rules should run for you? The model is intentionally simple.

Tier	What it covers
Free	The always-on safety domains: global, infrastructure, operations.
Paid	Everything in Free, plus ai-governance, business, and security.
Development add-on	An optional extra set of rules (development), purchased on top of Paid.
Trial	A new public user gets a time-boxed trial that runs at full Paid, then steps down to Free when it expires.

Who gets what:

• Logged in as a paying tenant (via nebcli login): Paid, plus the Development domain if that add-on was purchased.
• No login (a public user): Free, after the trial period.
• A tenant whose subscription lapses: falls back to Free automatically.

Your tier is read from a small, tamper-proof signed license. NebGuard carries the matching public key and verifies the license offline, so checking it never requires the network. Only the platform can issue a valid license, so a user cannot grant themselves a higher tier. The license is evaluated once at the start of each agent session and held steady for that whole session, which means any change to your tier takes effect at the start of your next session, never in the middle of one.

Two tools together

NebGuard licenses itself: nebguard setup includes a one-time signup, so it works without any other tool. If you are a NebCore tenant, NebCLI is a shortcut that hands NebGuard your license automatically:

• You run nebcli login once.
• nebcli fetches your signed license and writes it to ~/.nebcore on disk.
• NebGuard reads it from there at the start of your next session and activates your paid domains.

So nebcli is a convenience, not a requirement. If you install NebGuard on its own, its setup runs its own signup and gives you the trial and then the free guardrails; if you log in with nebcli later, your paid domains light up on the next session. There is no separate nebguard login. For the full picture, see NebCLI and NebGuard together.

Telemetry consent

NebGuard can report its guard decisions back to the platform so your team gets compliance evidence and so the product can improve. For a public user this is opt-in:

• You make an explicit choice when you sign up. The consent prompt cannot be skipped or bypassed.
• If you decline, you keep the full guardrails. Declining only stops telemetry from leaving your machine; it never reduces your protection.
• Public telemetry, when accepted, is anonymized and kept with short retention.

Any personal details you provide at signup are used only to issue and support your license. They are never cross-referenced with telemetry and never used for marketing or model training.

Air-gapped operation

NebGuard works in environments isolated from the public internet, where the platform backend runs locally. In that setup NebGuard behaves exactly as it does when connected: rule evaluation and license verification happen inside the binary with no network, and license delivery, signup, and telemetry all resolve to the local backend. There is no degraded mode and nothing special to configure. The only practical difference is how the binary itself is delivered, which is a packaging detail, not a behavior change.

Next steps

• Setup: install and verify NebGuard for Claude Code or Codex CLI.
• Examples: see a block, a guidance note, and an override-file idea.
• Guardrails for AI agents: the broader concept behind NebGuard.