Beyond CI/CD: Building Agentic Validation and Inspection Layers with LangGraph, MCP, and A2A

Modern CI/CD pipelines are exceptionally good at automation.

They compile code, run tests, build artifacts, scan dependencies, deploy infrastructure, and promote releases.

But there is an important difference between automating a deployment and reasoning about whether a change should be deployed.

Consider a pull request containing:

DROP TABLE customer_transactions;

Or:

DELETE FROM orders;

Or an application change that accidentally:

removes authorization middleware,
introduces an unsafe database operation,
exposes a secret,
changes an infrastructure security boundary,
bypasses an architectural convention,
deploys a breaking schema migration,
or modifies production resources outside the expected scope.

Traditional CI/CD can detect many of these problems when explicit rules already exist.

The harder problem is determining contextual risk.

Is this DROP statement part of an approved migration?

Does a DELETE contain an appropriate predicate?

Does the changed service still satisfy the system's architectural constraints?

Does the migration preserve compatibility with applications currently running in production?

Does a seemingly harmless configuration change expand the attack surface?

This is where an agentic inspection layer can complement—not replace—traditional CI/CD security controls.

The idea is simple:

Before production deployment, introduce a stateful reasoning layer that collects evidence from deterministic tools, evaluates the change from multiple perspectives, and produces an auditable deployment decision.

A practical architecture can combine:

deterministic linters and security scanners,
LangGraph and StateGraph,
specialized validation agents,
Model Context Protocol (MCP),
Agent2Agent (A2A) communication,
policy engines,
CI/CD status checks,
and human approval for high-risk operations.

This article develops that architecture from first principles.

1. Why Traditional CI/CD Is Necessary but Not Sufficient

A conventional pipeline often resembles:

Developer
↓
Pull Request
↓
Lint
↓
Unit Tests
↓
SAST / Dependency Scan
↓
Build
↓
Deploy Test
↓
Deploy Production

This architecture is essential.

NIST's Secure Software Development Framework recommends integrating secure development practices throughout the software development lifecycle rather than treating security as a final-stage activity.

OWASP similarly emphasizes that CI/CD infrastructure is itself security-sensitive because pipelines frequently have access to source code, credentials, artifacts, infrastructure, and deployment environments.

The problem is therefore not that traditional CI/CD is obsolete.

The problem is that most controls are intentionally specialized.

A SQL linter understands SQL.

A SAST engine understands known code patterns and data flows.

A dependency scanner understands packages and vulnerabilities.

A unit test validates expected behavior.

None necessarily understands the complete deployment context.

That distinction motivates a second layer.

1. Deterministic Validation vs Agentic Inspection

An important architectural rule is:

Never ask an LLM to replace a deterministic control when a deterministic control can reliably perform the job.

For example, SQL syntax should normally be validated using a SQL parser or linter.

SQLFluff provides dialect-aware SQL parsing and linting and can also work with templated SQL.

Similarly, source-code security analysis should continue using tools such as CodeQL, Semgrep, dependency scanners, secret scanners, and language-native test frameworks.

The agentic layer sits above those tools.

Instead of asking:

LLM → Is this SQL valid?

prefer:

SQL Parser
↓
SQL Linter
↓
Policy Rules
↓
Agentic Risk Analysis

The first three stages generate evidence.

The agent interprets that evidence within the broader deployment context.

This gives us a hybrid architecture:

Deterministic Controls
+
Contextual Agentic Reasoning
+
Human Governance

That combination is considerably safer than treating an LLM as a universal security scanner.

1. The Agentic CI/CD Inspection Architecture

A useful high-level architecture is:

                ┌───────────────────┐
                │   Pull Request    │
                └─────────┬─────────┘
                          │
                          ▼
                ┌───────────────────┐
                │ Change Detection  │
                └─────────┬─────────┘
                          │
                          ▼
                ┌───────────────────┐
                │ Gatekeeper Agent  │
                └─────────┬─────────┘
                          │
         ┌────────────────┼────────────────┐
         ▼                ▼                ▼
  Validation Agent   Security Agent    Review Agent
         │                │                │
         └────────────────┼────────────────┘
                          ▼
                ┌───────────────────┐
                │ Policy Evaluation │
                └─────────┬─────────┘
                          │
                ┌─────────┴─────────┐
                ▼                   ▼
             APPROVE              BLOCK
                │                   │
                ▼                   ▼
           Deployment        Human Review

I generally divide the system into four logical responsibilities.

Gatekeeper

The Gatekeeper determines what changed and what inspection path is required.

Examples:

Python changed
→ Python validation + security inspection

SQL changed
→ SQL parser + SQL policy inspection

Terraform changed
→ IaC security inspection

Dockerfile changed
→ container security inspection

The Gatekeeper should not blindly analyze the entire repository for every commit.

Its first responsibility is scope reduction.

1. Validation Agent

The Validation Agent answers:

Is the proposed change structurally valid?

For Python, this might include:

ruff check .
pytest
mypy .

For SQL:

sqlfluff lint migrations/

For infrastructure:

terraform validate

For containers:

docker build .

The important point is that the agent does not invent validation.

It orchestrates established tools and normalizes their results.

Conceptually:

validation_result = {
"syntax": "PASS",
"tests": "PASS",
"lint": "PASS",
"violations": []
}

That becomes evidence for subsequent agents.

1. Security Inspection Agent

The Security Agent focuses on exploitable or operationally dangerous changes.

Its inputs may include results from:

CodeQL
Semgrep
Secret Scanner
Dependency Scanner
IaC Scanner
SQL Policy Engine
Container Scanner

For example:

security_result = {
"critical": 0,
"high": 1,
"medium": 3,
"secrets_detected": False
}

The agent can then evaluate those findings alongside the actual code diff.

This distinction matters.

A scanner detects findings.

The agent helps reason about their deployment significance.

1. Dangerous SQL Deserves Its Own Gate

Database changes are particularly interesting because perfectly valid SQL can still be operationally catastrophic.

Consider:

DELETE FROM customer_orders;

This may be syntactically valid.

But the absence of a WHERE clause can make it extremely dangerous.

Likewise:

DROP DATABASE production;

may be syntactically valid while obviously requiring exceptional authorization.

Other operations worth policy inspection include:

DROP TABLE
DROP SCHEMA
TRUNCATE TABLE
DELETE without WHERE
UPDATE without WHERE
ALTER TABLE DROP COLUMN
GRANT
REVOKE
CREATE OR REPLACE

But naive keyword blocking is insufficient.

For example:

DROP TABLE temp_integration_test;

inside an isolated ephemeral environment may be perfectly acceptable.

Therefore the inspection decision should consider:

Statement
+
Environment
+
Object classification
+
Migration context
+
Permissions
+
Dependencies
+
Policy

This is where agentic reasoning becomes useful.

1. Build an AST, Not a Regex Security System

One mistake I would avoid in production is implementing SQL security entirely with expressions such as:

if "DROP" in sql.upper():
reject()

This is fragile.

SQL has:

comments,
aliases,
nested statements,
stored procedures,
dialect differences,
templating,
dynamic SQL,
quoted identifiers.

A stronger architecture parses SQL into an Abstract Syntax Tree.

Conceptually:

SQL
↓
Lexer
↓
Parser
↓
AST
↓
Policy Engine
↓
Risk Evaluation

For example:

DELETE
├── target: customer_orders
└── where: null

Now the policy engine can reason structurally:

if statement.type == "DELETE" and statement.where is None:
risk = "CRITICAL"

This is far more reliable than substring matching.

1. Why LangGraph Fits This Problem

A deployment gate is not naturally a single prompt.

It is a workflow.

LangGraph models workflows using:

state,
nodes,
edges,
conditional edges.

That maps remarkably well to CI/CD inspection.

Our shared state could look conceptually like:

class PipelineState(TypedDict):
changed_files: list[str]
validation_results: dict
security_results: dict
sql_results: dict
architecture_results: dict
risk_score: int
decision: str

Then define nodes:

detect_changes
validate
inspect_security
inspect_sql
review_architecture
calculate_risk
deployment_gate

And connect them:

START
↓
detect_changes
↓
validate
↓
inspect_security
↓
inspect_sql
↓
review_architecture
↓
calculate_risk
↓
deployment_gate
↓
END

But real pipelines need branching.

That is where StateGraph becomes especially useful.

1. Conditional Routing

Suppose only documentation changed.

Running database inspection makes little sense.

We can route dynamically:

def route_change(state):
files = state["changed_files"]

if any(f.endswith(".sql") for f in files):
    return "sql_inspection"

if any(f.endswith(".py") for f in files):
    return "code_validation"

return "lightweight_review"

The graph then represents deployment policy explicitly.

Conceptually:

            Change Detector
                 │
      ┌──────────┼───────────┐
      ▼          ▼           ▼
    SQL        Python       Docs
      │          │           │
      ▼          ▼           ▼
 SQL Agent   Code Agent   Lightweight
      │          │           Review
      └──────────┼───────────┘
                 ▼
              Review
                 ↓
              Decision

This is substantially easier to audit than hiding the entire decision process inside one enormous system prompt.

1. The Review Agent

The Review Agent asks a different question:

Even if the change is technically valid, does it make architectural sense?

Imagine a service that previously used:

API
↓
Service Layer
↓
Repository
↓
Database

A developer introduces:

API
↓
Direct Database Query

The code may:

compile,
pass tests,
pass SQL linting,
contain no obvious vulnerability.

But it may violate an established architecture.

A Review Agent can compare the diff against architecture policies stored in repository documentation or structured policy resources.

For example:

architecture/
principles.md
service-boundaries.yaml
database-policy.yaml
security-policy.yaml

The output might be:

{
"status": "WARN",
"rule": "ARCH-DB-004",
"reason": "API layer directly accesses persistence layer",
"confidence": 0.94
}

Critically, this should usually be treated as decision-support evidence, not unquestionable truth.

1. MCP: Standardizing Tool Access

Our agents need tools.

The SQL agent may need:

SQL parser
Schema metadata
Dependency graph
Migration history

The Security Agent may need:

SAST results
Dependency scanner
Secret scanner
Repository metadata

The Review Agent may need:

Architecture documents
Policy repository
Pull-request diff
Service catalog

Hard-coding every integration directly into every agent quickly becomes difficult to maintain.

This is where Model Context Protocol becomes useful.

MCP defines a client-server architecture through which servers can expose primitives including:

tools,
resources,
prompts.

A conceptual deployment architecture becomes:

Agent
│
MCP Client
│
├── Repository MCP Server
├── SQL MCP Server
├── Security MCP Server
├── Policy MCP Server
└── Deployment MCP Server

For example:

SQL MCP Server

tools:
parse_sql
inspect_schema
calculate_dependency_impact

resources:
schema://production
migrations://history

This creates a clean separation between:

Reasoning

and:

System Access

That separation is extremely valuable in production agent architectures.

1. MCP Does Not Automatically Make Tools Safe

This point deserves emphasis.

MCP standardizes interaction.

It does not magically make every exposed operation trustworthy.

The MCP specification explicitly treats tool execution as security-sensitive and recommends strong user control, authorization, and data protection.

Therefore a production CI/CD MCP server should enforce:

Authentication
Authorization
Least privilege
Input validation
Audit logging
Rate limiting
Environment boundaries
Credential isolation

A SQL inspection agent, for example, should normally receive read-only metadata access.

It should not automatically receive credentials capable of executing:

DROP DATABASE production;

Tool permissions must follow the principle of least privilege.

1. Where A2A Fits

MCP and A2A solve different architectural problems.

A useful mental model is:

MCP
Agent ↔ Tools / Resources

A2A
Agent ↔ Agent

A2A is designed for interoperability between independent agent systems.

That becomes useful when validation responsibilities are separated into independently deployed services.

For example:

                Orchestrator
                     │
          ┌──────────┼───────────┐
          │          │           │
          ▼          ▼           ▼
      SQL Agent   Security    Architecture
                    Agent        Agent

Each agent could be independently:

deployed,
versioned,
secured,
scaled,
owned by another team,
or implemented using a different agent framework.

A2A provides a standardized interaction model between such agents.

1. MCP + A2A Together

Now the architecture becomes more interesting.

                CI/CD Pipeline
                      │
                      ▼
             LangGraph Orchestrator
                      │
             A2A Coordination Layer
          ┌───────────┼───────────┐
          ▼           ▼           ▼
    Validation     Security      Review
      Agent         Agent        Agent
          │           │           │
          └──── MCP Tool Layer ───┘
                      │
   ┌──────────────────┼─────────────────┐
   ▼                  ▼                 ▼

Repository MCP Security MCP SQL MCP
│ │ │
▼ ▼ ▼
Git Provider Code Scanners Database

LangGraph manages workflow state.

A2A handles communication between independently operating agents.

MCP provides controlled access to tools and contextual resources.

Traditional security tooling produces deterministic evidence.

The CI/CD platform enforces the final deployment gate.

Each technology therefore has a distinct responsibility.

1. Never Give the LLM the Final Word

This may be the most important production rule in the article.

Do not implement:

if llm_response == "SAFE":
deploy_production()

Instead:

Deterministic Evidence
↓
Agentic Analysis
↓
Policy Engine
↓
Risk Classification
↓
Human Approval if Required
↓
CI/CD Gate

The final decision should be constrained by explicit policy.

For example:

if critical_security_findings > 0:
decision = "BLOCK"

elif destructive_sql_detected:
decision = "HUMAN_APPROVAL"

elif test_coverage_failed:
decision = "BLOCK"

elif architecture_risk == "HIGH":
decision = "HUMAN_APPROVAL"

else:
decision = "PASS"

The LLM contributes evidence and contextual reasoning.

It does not become an unrestricted production administrator.

1. Risk-Based Deployment Gates

Binary pass/fail is sometimes insufficient.

A better system can classify deployment risk.

Example:

0–20 LOW
21–50 MEDIUM
51–75 HIGH
76–100 CRITICAL

Signals might include:

Critical vulnerability +50
Secret detected +50
DROP/TRUNCATE +40
DELETE without WHERE +40
Breaking schema change +30
Architecture violation +20
Insufficient tests +15
Large dependency impact +15

Then:

LOW
→ automatic continuation

MEDIUM
→ continue + warning

HIGH
→ mandatory reviewer approval

CRITICAL
→ deployment blocked

The exact weights should be calibrated using organizational incidents, false-positive analysis, and risk appetite rather than copied blindly from an example.

1. Explainability Must Be Part of the Contract

An agentic deployment gate should never simply return:

DEPLOYMENT BLOCKED

A useful result looks more like:

{
"decision": "BLOCK",
"risk": "CRITICAL",
"score": 92,
"findings": [
{
"file": "migrations/042_cleanup.sql",
"line": 18,
"type": "UNBOUNDED_DELETE",
"evidence": "DELETE statement contains no WHERE clause"
}
],
"required_action": "Add predicate or obtain destructive-operation approval"
}

This provides:

evidence,
location,
policy,
severity,
remediation.

That transforms an AI gate from a mysterious reviewer into an auditable engineering control.

1. Human-in-the-Loop Is a Feature

Some operations should intentionally stop automation.

For example:

DROP production table
Major IAM change
Destructive migration
High-confidence architecture violation
Production network change
Critical scanner finding

The graph can interrupt:

Agent Analysis
↓
HIGH RISK
↓
Human Approval
↙ ↘
Reject Approve
↓ ↓
STOP Continue

LangGraph's persistence and human-in-the-loop capabilities are particularly useful for workflows that must pause and later resume.

This makes the system appropriate for controlled production environments where automation must coexist with governance.

1. A Production Reference Flow

Putting everything together:

Developer Push
↓
Pull Request
↓
Changed File Detection
↓
Traditional CI
┌────┼─────┐
│ │ │
Lint Test SAST
└────┼─────┘
↓
Agentic Inspection Layer
↓
LangGraph StateGraph
↓
Gatekeeper
↓
┌───────────────┐
│ Parallel │
│ Inspection │
└───────────────┘
↓ ↓ ↓
Validation Security SQL
↓ ↓ ↓
└──────┼──────┘
↓
Architecture Review
↓
Policy Engine
↓
Risk Score
↓
┌────────┼────────┐
▼ ▼ ▼
PASS REVIEW BLOCK
│ │
│ Human
│ Approval
│ │
└────────┘
↓
Artifact Build
↓
Test Deployment
↓
Smoke Tests
↓
Production Gate
↓
Production

1. What Should Remain Deterministic?

A good rule of thumb:

Problem Preferred mechanism
Syntax Parser/compiler
Formatting Linter
Unit behavior Tests
Known vulnerabilities SAST/SCA
Secrets Secret scanner
SQL structure SQL parser
Policy invariants Policy engine
Contextual impact Agent
Architecture reasoning Agent + policy
Cross-system investigation Agent
Final critical approval Human/policy

This separation is essential.

Agentic systems become more trustworthy when they are surrounded by deterministic boundaries.

1. Production Safeguards

If I were implementing this architecture for an enterprise pipeline, I would consider these controls non-negotiable:

Agents receive minimum required permissions.
Production inspection should prefer read-only access.
LLM-generated SQL must never execute automatically merely because the model considers it safe.
Scanner findings remain authoritative evidence rather than being silently overridden by an LLM.
Critical operations require deterministic policy gates.
Every agent decision should be logged with evidence and policy identifiers.
Prompt injection must be considered because repository files, PR descriptions, comments, and documentation can all contain untrusted text.
Tool outputs must be validated before they enter downstream workflows.
MCP tools should expose narrowly scoped capabilities rather than generic shell/database access.
Credentials should be short-lived and environment-scoped wherever possible.
Agent outputs should use structured schemas rather than unconstrained natural language.
High-risk deployment decisions should support human review.

1. The Bigger Architectural Shift

The interesting evolution is not:

CI/CD → AI

It is:

Automation
↓
Evidence
↓
Reasoning
↓
Policy
↓
Governance
↓
Deployment

Traditional CI/CD answers:

Can this software be built and deployed?

An agentic inspection layer adds another question:

Given the available evidence, organizational policy, architecture, environment, and potential blast radius, should this particular change proceed automatically?

That is a much richer engineering problem.

And it is exactly why technologies such as LangGraph, MCP, and A2A become interesting in DevSecOps—not because we need an LLM inside every pipeline stage, but because complex delivery environments increasingly require stateful coordination across tools, policies, agents, and humans.

Conclusion

Agentic CI/CD should not replace deterministic CI/CD.

It should sit above it as an inspection and decision-support layer.

The architecture I would advocate is:

LangGraph
→ stateful orchestration

StateGraph
→ explicit nodes, state, and conditional control flow

MCP
→ standardized access to tools and contextual resources

A2A
→ interoperability between independently deployed agents

SAST / linters / parsers / tests
→ deterministic technical evidence

Policy engine
→ enforceable organizational rules

Human approval
→ governance for high-risk operations

The result is not merely a pipeline that executes faster.

It is a pipeline capable of collecting evidence, understanding deployment context, escalating uncertainty, and protecting production boundaries before a risky change reaches them.

That is the direction I expect serious agentic DevSecOps architectures to move toward:

deterministic where possible, agentic where useful, and human-controlled where consequences matter.

References
NIST — Secure Software Development Framework (SSDF), SP 800-218
https://csrc.nist.gov/pubs/sp/800/218/final
OWASP — CI/CD Security Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html
LangChain — LangGraph Graph API / StateGraph
https://docs.langchain.com/oss/python/langgraph/graph-api
LangChain — LangGraph v1
https://docs.langchain.com/oss/python/releases/langgraph-v1
Model Context Protocol — Architecture
https://modelcontextprotocol.io/docs/learn/architecture
Model Context Protocol — Specification
https://modelcontextprotocol.io/specification/2025-11-25
Agent2Agent Protocol — Specification
https://a2a-protocol.org/dev/specification/
SQLFluff — SQL Linter Documentation
https://docs.sqlfluff.com/en/stable/
GitHub — CodeQL Code Scanning Documentation
https://docs.github.com/en/code-security/reference/code-scanning/codeql
OpenSSF — Scorecard
https://openssf.org/projects/scorecard/