Skip to main content

Guardrails for AI Agents

Overview​

An AI coding agent takes real actions on your behalf: it runs commands, edits files, commits and pushes code, and changes infrastructure. Most of those actions are fine, but a few are dangerous and many are simply off-course. Guardrails are a policy layer that sits between the agent and its actions, checks each one against a set of rules, and decides what to do about it. NebGuard is NebCore's implementation of this pattern. This page explains the concept; for the product, see the NebGuard overview.

Why agents need guardrails​

Agents are fast and mostly correct, which is exactly what makes the rare bad action costly. A single force-push to a protected branch, a deleted production resource, or a committed secret can do real damage, and unlike a human the agent will execute it without hesitation. Separately, an agent can drift: it wanders from the task, repeats work, or skips a verification step, quietly burning time and tokens. Guardrails address both. They catch the dangerous actions before they run, and they nudge the agent back toward the task, while staying out of the way for the ordinary actions that make up most of a session.

When guardrails run​

Guardrails do not run continuously. They run at the meaningful points in the agent's lifecycle: when the agent is about to take an action, and at moments around the work such as starting up, finishing a turn, and after the agent trims its own context. Checking before an action is what makes blocking possible. Checking around the work is what makes guidance, warnings, and an audit trail possible. The point is qualitative: guardrails fire when a decision can still change the outcome, not on a fixed timer.

The four responses​

At each of those moments, a guardrail responds in one of four ways:

ResponseMeaning
AllowThe action is safe and proceeds untouched.
WarnThe action is risky. A note is attached so the agent and the human can reconsider.
BlockThe action is dangerous and is stopped before it runs.
GuideContext is injected to keep the agent on course, and key constraints are re-stated after the agent trims its context.

Only the check before an action can block. The others observe, warn, guide, or record. Critical guards are built to fail safe: a high-stakes guard that cannot be evaluated becomes a block rather than letting the action slip through, and the most dangerous blocks cannot be bypassed by the agent writing its own justification.

Rule domains​

Rules are grouped by the part of the work they protect. NebGuard organizes them into seven domains:

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

Grouping by domain makes it clear what a rule is for and lets entitlement and environment decide which groups are active for a given user.

Compliance evidence​

Because every guardrail decision is recorded with enough detail to attribute it, guardrails double as a source of compliance evidence. Each decision carries enough context to map to the controls your compliance and security reviews care about, so an audit trail of what the agent did, and what was allowed, warned, blocked, or guided, falls out of normal operation rather than being assembled after the fact.

Next steps​