Skip to main content

What are Agentic Guardrails?


In my previous post, I discussed two broad execution models for Agentic Systems:

  1. Programmatically Orchestrated Systems – where an application/framework controls execution.

  2. Prompt-Orchestrated Systems – where the LLM itself plans and executes based on prompts, agent definitions, skills and workflows.

Once you understand this distinction, the next obvious question is:

What exactly are Guardrails?

Many people equate guardrails with AI safety:

  • Prevent prompt injection

  • Block harmful content

  • Protect secrets

  • Prevent data leakage

These are certainly guardrails, but they represent only one category.

For Agentic SDLC, guardrails are much broader.

Guardrails are constraints, policies, validations, or controls that influence or verify an agent's behavior before, during, or after execution.

Think of them across the entire lifecycle.

1. Input Guardrails

Applied before execution begins.

Examples:

  • Validate that requirements are complete.

  • Detect ambiguous instructions.

  • Require missing acceptance criteria.

  • Verify referenced files exist.

  • Reject unsupported technologies.

Purpose:
Improve the quality of the work before the agent starts reasoning.

2. Execution Guardrails

Applied while the agent is working.

Examples:

  • Restrict tool usage.

  • Limit file modifications.

  • Require approvals before destructive actions.

  • Control workflow sequencing.

  • Enforce retry and timeout policies.

Purpose:
Control how the agent operates.

3. Knowledge Guardrails

Control what information the agent can use.

Examples:

  • Use only approved documentation.

  • Prefer enterprise coding standards.

  • Restrict external internet access.

  • Use only approved APIs.

  • Require citations for generated documentation.

Purpose:
Improve consistency and reduce hallucinations.

4. Engineering Quality Guardrails

This is the category I believe is currently underrepresented in most AI coding discussions.

Examples:

  • Enforce modular architecture.

  • Apply SOLID principles.

  • Minimize coupling.

  • Maximize cohesion.

  • Keep components focused.

  • Require unit tests.

  • Consider performance.

  • Consider accessibility.

  • Consider observability.

  • Apply secure coding practices.

Purpose:
Improve long-term software quality rather than simply producing working code.

5. Output Guardrails

Applied after generation.

Examples:

  • Linting.

  • Schema validation.

  • API contract validation.

  • Static analysis.

  • Security scanning.

  • Test execution.

  • Formatting.

Purpose:
Verify that generated artifacts meet expected standards.

6. Governance Guardrails

Control organizational compliance.

Examples:

  • Human approval before merge.

  • Audit trails.

  • Traceability.

  • Compliance validation.

  • License checks.

  • Architecture review.

Purpose:
Ensure organizational governance is maintained even when AI performs much of the work.

The implementation depends on the execution model

This is where the discussion becomes interesting.

In Programmatically Orchestrated Systems, many guardrails are executable.

The framework can literally prevent an action from happening.

Examples:

  • Block tool execution.

  • Reject invalid input.

  • Stop the workflow.

  • Require approval.

  • Validate outputs before continuing.

The application enforces the rules.

In Prompt-Orchestrated Systems (for example, many GitHub Copilot + VS Code agent workflows), the situation is different.

Most guardrails are instructions given to the LLM.

The model is expected to:

  • follow the workflow,

  • apply engineering standards,

  • perform self-review,

  • ask clarification questions,

  • generate tests.

But unless an external mechanism validates the result, these guardrails are largely advisory rather than enforceable.

This distinction explains why simply adding more instructions to an agent often produces inconsistent behavior.

The challenge is no longer writing better prompts.

The challenge is designing guardrails that can be consistently applied and, wherever possible, independently validated.

In the final post, I'll discuss practical ways to implement guardrails for AI-native SDLC, especially for prompt-orchestrated environments such as GitHub Copilot, where deterministic enforcement is limited.

Comments

Popular posts from this blog

Example 1: ArchiMate relationship in PlantUML code to demonstrate 15 relationship types

 Following section presents 15 types of relationships in ArchiMate and PlantUML to generate the diagram. Since this code is generated by GEN-AI it may require precision on aspects other than PlantUML syntax: Diagram Plant UML Code:  @startuml '!includeurl https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/Archimate.puml ' Another way of including Archimate Library (above is commented for following) !include <archimate/Archimate> !theme archimate-standard from https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/themes title ArchiMate Relationships Overview <style> element{     HorizontalAlignment: left;     MinimumWidth : 180;     Padding: 25; } </style> left to right direction rectangle Other {     Business_Role(Role_SeniorManager, "Senior Manager")     Business_Role(Role_Manager, "Manager") } rectangle Dynamic {     Business_Event(Event_CustomerReques...

Examples 7: ArchiMate flow relationship between elements in layers

Diagram Code @startuml !include < archimate / Archimate > < style > element {     HorizontalAlignment : left ;     MinimumWidth : 180 ;     Padding : 20 ; } note {     BackgroundColor : #FFFFCC ;     RoundCorner : 5 ;     MaximumWidth : 250 ; } </ style > title "ArchiMate 3.2 Valid Flow Relationships" left to right direction ' Business Layer Flow Relationships rectangle "Business Layer Flows" {     Business_Process ( bp1 , "Order Process" )     Business_Process ( bp2 , "Payment Process" )     Rel_Flow ( bp1 , bp2 , "Order data" )     note on link         Flow between Business Processes     end note         Business_Function ( bf1 , "Sales Function" )     Business_Function ( bf2 , "Delivery Function" )     Rel_Flow ( bf1 , bf2 , "Sales information" )     note on link     ...

Mastering Trade-Off Analysis in System Architecture: A Strategic Guide for Architects

 In system architecture and design, balancing conflicting system qualities is both an art and a science. Trade-off analysis is a strategic evaluation process that enables architects to make informed decisions that align with business goals and technical constraints. By prioritizing essential system attributes while acknowledging inevitable compromises, architects can craft resilient and efficient solutions. This enhanced guide provides actionable insights and recommendations for architects aiming to master trade-off analysis for impactful architectural decisions. 1. Understanding Trade-Off Analysis Trade-off analysis involves identifying and evaluating the conflicting requirements and design decisions within a system. Architects must balance critical aspects like performance, scalability, cost, security, and maintainability. Since no system can be optimized for every quality simultaneously, prioritization based on project goals is essential. Actionable Insights: Define key quality ...