Guardrails are engineering, not wording

Most enterprise AI safety conversations start with better prompts. Teams write longer system messages and add a list of forbidden behaviors. Then they hope the agent stays within the rules.

That helps, but it is not enough, and it is not really the point. A guardrail that only exists as instruction text has no way to stop a model from acting on it. What actually stops an unwanted action is code: a validation check, a permission lookup, a schema that rejects malformed output, a gate that requires a human signature before something executes. This piece is about that layer — the deterministic checks around the model, not the words fed into it.

The real risk in enterprise workflows is not only that the model says something wrong. The risk is that the model can take an action it should not take. It is also that an employee slowly steers the agent toward an outcome that would normally need approval.

In a procurement or finance workflow, that might mean:

  • exposing supplier data to the wrong user,
  • drafting a message that changes payment expectations,
  • unblocking a supplier without valid certification,
  • creating a purchase order outside the user’s authority,
  • accepting a contract term that legal would normally review.

Those are not prompt problems. They are control problems.

Prompt abuse often happens slowly

The obvious misuse case is easy to imagine. Someone asks an internal agent to ignore policy and approve something it should not approve.

Good systems should catch that.

The harder case is drift. A user starts with a harmless request. Then they ask a slightly more specific follow-up. Then they ask another. Each step looks reasonable on its own. Across the full conversation, the user is moving the agent toward an action outside their role.

Consider a procurement agent scoped to one business unit. A buyer opens with “summarize open POs for supplier X” — harmless. Three messages later, the same buyer asks the agent to draft an email raising a $180,000 PO’s unit price by 4%, a change that would normally route through a $50,000 approval tier. No single message in that five-turn thread looks like misuse. Only the full tool-call log shows the buyer steadily walked the agent past their own authority.

That is why guardrails cannot inspect only the latest message. They need to inspect:

  • the user’s role,
  • the business object being accessed,
  • the full conversation path,
  • the action the agent is about to call,
  • the consequences of that action.

In practice, this means the safety layer must run across the conversation, not just the next prompt.

RBAC must follow the agent into every tool

Role-based access control is already familiar in enterprise software. The mistake is treating AI as a new front door that bypasses it.

If a user cannot unblock a vendor in Ariba, the agent should not do it for them. If a user can view an invoice but not approve payment, the agent should inherit the same boundary.

Enterprise agents need user context attached to every tool call:

  • who is asking,
  • what role they have,
  • which company, department, or commodity they belong to,
  • which record they are touching,
  • which action is being attempted,
  • whether that action requires a human approval step.

RBAC is not a static list inside the prompt. It is enforcement at the action layer.

Put checks before the large model

Large model calls are expensive in latency and cost. Many checks should happen before the main model runs.

Pre-model checks can block or route obvious issues:

  • Is the user allowed to access this supplier, invoice, or contract?
  • Is the requested action in scope for this agent?
  • Does the request include confidential data that should not enter the model?
  • Is the message trying to override policy?
  • Is there a safer template or workflow that should handle this request?

Some teams use smaller policy models or classifiers for this layer. Others use simple rules for known business limits. The important point is architectural. Do not ask the most powerful model to decide every safety question after it has already received the risky input.

Where the checks physically live

In many agent systems, the model does not do business work directly. It calls tools: query SAP, fetch invoice status, read vendor master data, draft email, create a task, update a record.

The guardrail discipline here is simple to state and easy to skip in practice: every check above needs a concrete home outside the prompt — a validation function, a permission lookup, a rate limiter, a masking rule, a logging hook — sitting between the model’s tool call and the system it touches. (The specific pattern for wiring that layer, using MCP as the protocol, is its own topic; what matters here is that the checks are code, versioned and testable, not instructions the model might follow.)

This also keeps the system flexible. If the company later changes model providers, the validation and permission layer does not need to be rebuilt from scratch. The agent can change. The controlled action surface stays in place.

Human approval is a control, not a weakness

For sensitive enterprise workflows, full autonomy is often the wrong first goal.

The better pattern is:

  1. AI gathers the evidence.
  2. AI prepares the draft or recommendation.
  3. The system validates policy and permissions.
  4. A human approves actions that affect money, suppliers, contracts, compliance, or customer commitments.

This is especially important in procurement. AI can compare contract payment terms with the purchase requisition. It can check whether a supplier certificate is missing. It can flag that an invoice amount exceeds the milestone. But the final approval should belong to a named owner.

That is how you get speed without losing accountability.

Logs are part of the guardrail

If an auditor asks why a vendor was approved, the answer cannot be “the agent decided.”

A useful AI workflow should retain:

  • the user request,
  • the records and documents used,
  • the model output,
  • the policy checks that passed or failed,
  • the human approver,
  • the final action,
  • the reason for any override.

This turns AI from a mysterious assistant into a controlled workflow participant.

Guardrails improve over time

At day zero, you will not know every boundary condition. Real misuse patterns and edge cases appear after teams use the system.

That is another reason to treat guardrails as a living control layer:

  • review failed and blocked requests,
  • inspect conversations that reached human escalation,
  • add rules for newly discovered policy gaps,
  • tune smaller classifiers for drift patterns,
  • update approval thresholds as the workflow matures.

The first version should be strict. Trust can expand after the workflow has evidence.

Nond.ai’s position: prompt wording is not a control system. What holds up under audit is RBAC, pre-model checks, tool-layer boundaries, logging, and approval gates sized to the actual risk.