Original Red Hat presentation
AI Agents in CI/CD
Security, Robustness, and Productivity · NCSU · September 9, 2026
The Red Hat presentation is preserved as the primary version. Use the controls or keyboard to move through the deck.
Open standalone notes in a new tab
Show transcript for slide 1
AI Agents in CI/CD:Security, Robustness, and ProductivityA Deep Dive from Theory to ProductionAndre Lustosa, PhD Principal Software Engineer | Red Hat | AIPCC Ecosystems1
Show transcript for slide 2
Lecture OutlineI. Foundations Agent architectures, delegation, and the confused deputyII. Security Theory Injection taxonomy, trust boundaries, containment primitivesIII. Robustness Non-determinism, convergence, cycle detection, action-space reductionIV. Measurement Productivity quantification, automation bias, human-in-the-loop controlV. Open Problems Formal verification, alignment in CI, research frontiers2
Show transcript for slide 3
I. FOUNDATIONSAgent Architecture: From Theory to Tool-Use LLMsAgent Model Tool-Use LLM as UTM Analog▸ Sense: read files, API responses, CI logs ▸ LLM + tools = Turing-complete system▸ Reason: LLM inference (probabilistic) ▸ Tape: filesystem, git repos, APIs▸ Act: write files, run commands, call APIs ▸ Head: tool-use function calls▸ Loop: observe outcome, adjust, repeat ▸ Control: learned policy (weights), not program▸ Halting: not guaranteed (token limits as proxy)Key distinction from classical AI agents: the reasoning Consequence: you cannot statically determine what an agentengine is a neural network with no formal guarantees on will do. All safety must be enforced at the environmentoutput correctness. boundary.3
Show transcript for slide 4
I. FOUNDATIONSThe “Principal-Agent” Problem in AI Automation▸ Economics: principal delegates to agent with misaligned incentives▸ In AI CI/CD: the organization delegates code changes to an LLM agent▸ Information asymmetry: agent 'sees' codebase details principal doesn't verify▸ Moral hazard: agent may take shortcuts invisible at review time▸ Adverse selection: which tasks are suitable for delegation?The classical solution is monitoring + incentives. For LLM agents, monitoring = code review + gates + telemetry.'Incentives' = prompt engineering + structured output constraints. Neither is complete.4
Show transcript for slide 5
I. FOUNDATIONSThe Confused Deputy RevisitedClassic Confused Deputy (1988) LLM Agent as Confused Deputy▸ Program A has authority to write billing file ▸ Agent has git push + API credentials (authority)▸ User B tricks A into writing user-controlled data ▸ Attacker embeds instructions in a bug ticket (trick)▸ A acts on B's behalf using A's privileges ▸ Agent executes attacker's intent with org's credentials▸ Root cause: ambient authority not scoped to intent ▸ Root cause: identical. Ambient authority + untrustedinputMitigation: Capability-Based SecurityReplace ambient authority with explicit capabilities. The agent receives only the permissions it needs for the specific task, scopedby ticket, repo, and time window. This is the theoretical basis for our gate architecture.5
Show transcript for slide 6
II. SECURITYInjection Attack Taxonomy: Why Prompt Injection isDifferentAttack Class Mechanism Defense Why It WorksSQL Injection Untrusted data interpreted as SQL Parameterized queries Grammar-based separationXSS Untrusted data interpreted as script Output encoding / CSP Context-aware escapingCommand Injection Untrusted data interpreted as shell Avoid shell; use execve Argument isolationPrompt Injection Untrusted data interpreted as ??? No grammar to parseinstructionEvery prior injection class was solved by separating data from code at a syntactic level. Prompt injection cannot be solved thisway because natural language has no formal grammar that distinguishes instruction from data.6
Show transcript for slide 7
II. SECURITYTrust Boundary AnalysisFormal decomposition: Who provides input? What authority does the agent hold? When is output trusted?WHO (Identity Layer) WHAT (Authority Layer) WHEN (Temporal Layer)▸ Trigger author (changelog-verified) ▸ Git push to specific branches ▸ Pre-agent: input filtering▸ Comment authors (email-domain ▸ MR/PR creation and update ▸ During: runtime containmentfiltered) ▸ Issue tracker mutations ▸ Post-agent: output validation▸ External reporters (quarantined) ▸ Network egress (sandboxed) ▸ Post-merge: monitoring▸ The LLM itself (not a trusted source)7
Show transcript for slide 8
II. SECURITYCase Study: Defense in Depth in ProductionCase Study: Red Hat Agentic CI gate architecture (production since 2025)PRE-AGENT POST-AGENT▸ Label author: @redhat.com via Jira changelog API ▸ Sensitive files: blocks .env, .pem, .key commits▸ External reporter gate: quarantine + human review ▸ Secret scan: gitleaks on all commits pre-push▸ Comment filter: only @redhat.com in prompt ▸ Commit identity: author matches expected bot▸ Embargo: JQL excludes EMBARGOED tickets ▸ Visibility: comments restricted to employees▸ AI sensitivity: semantic security-bug detectione.g: https://opendatahub-io.github.io/agentic-ci/api/gates/8
Show transcript for slide 9
II. SECURITYContainment Primitives: Kernel-Level EnforcementLandlock (Linux 5.13+)Filesystem access control via LSM. Process declares which paths it can read/write. Restrict agent to workspace directory +Inherited by children. No root required. read-only depsseccomp-bpfSystem call filtering via BPF programs. Blocks dangerous syscalls (ptrace, mount, Prevent container escape and privilegekexec). Granular per-process policy. escalationNetwork Namespaces + nftablesPer-sandbox network stack with firewall rules. Allowlist-only egress. No ambient Block exfiltration to attacker-controllednetwork access. endpointsThese are kernel-level enforcement mechanisms. The agent cannot bypass them regardless of prompt injection success.9
Show transcript for slide 10
II. SECURITYCase Study: Sandboxing in ProductionCase Study: OpenShell sandbox in Red Hat Agentic CI▸ Embedded gateway starts per CI job, no external infrastructure▸ Landlock: agent writes only to /workspace, reads only approved paths▸ Network: allowlist of endpoints (configurable per-repo via .agentic-ci/openshell-policy.yml)▸ Default allowlist: GitHub, GitLab, PyPI, Vertex AI, Anthropic API▸ Credentials mounted read-only, never exposed as environment variables in the sandbox▸ All other outbound traffic silently dropped (not rejected, to avoid side-channel leaks)Design principle: the sandbox is the security boundary, not the prompt. If you rely on prompt instructions for safety,you've already lost.10
Show transcript for slide 11
II. SECURITYThe Oracle Problem: Limits of Output Verification▸ Can you formally verify that LLM output is 'safe'?▸ Rice's theorem: any non-trivial semantic property of programs is undecidable▸ The generated code IS a program. Verifying its safety is at least as hard as the halting problem.▸ Practical implication: you cannot build a gate that provably catches all malicious output▸ What you CAN do: reduce the attack surface until the residual risk is manageableThe Defense Stack (ordered by enforceability)▸ 1. Kernel enforcement (Landlock, seccomp, netfilter) - cannot be bypassed by the agent▸ 2. Structural validation (gitleaks, file-path checks) - syntactic, decidable▸ 3. Semantic analysis (AI-powered review) - probabilistic, best-effort▸ 4. Human review - highest quality, lowest throughput11
Show transcript for slide 12
III. ROBUSTNESSNon-Determinism in Agentic SystemsSources of Non-Determinism Consequences for CI/CD▸ Sampling temperature (even at T=0, not deterministic) ▸ Same bug + same prompt = different patches▸ Context window position effects ▸ Retry may produce better OR worse results▸ Batching and quantization artifacts ▸ Test suite pass is necessary but not sufficient▸ Tool output variance (git diff timing, API responses) ▸ Idempotency cannot be assumed▸ Prompt sensitivity to minor wording changes ▸ Statistical reliability, not deterministic correctnessMitigation Strategies▸ Structured output schemas: constrain output space to valid shapes▸ Verdict-based skill design: agent must declare intent before acting▸ Idempotent gate design: gates are safe to re-run on retry▸ Monotonic state machines: workflow state can only move forward, never back12
Show transcript for slide 13
III. ROBUSTNESSConvergence and Divergence in Feedback LoopsWhen does a closed-loop agentic system converge to a fixed point?Convergent Patterns Divergent Patterns▸ Bug fix iteration: review feedback narrows the solution ▸ Self-healing loops without cycle detection▸ Bounded retry with monotonic state ▸ Agent 'fixes' its own fixes (oscillation)▸ Human checkpoint breaks infinite loops ▸ Expanding scope: agent adds features while fixing bugs▸ CI pass/fail provides a decidable termination criterion ▸ Cost explosion: each retry consumes tokens▸ Diminishing error surface per iteration ▸ Cascading failures across dependent pipelines13
Show transcript for slide 14
III. ROBUSTNESSCase Study: Cycle Detection in Self-Healing CICase Study: Pipeline Failure Analyzer-Autofix cycle prevention at Red HatAutofix PFA Creates Autofix Would FixPipeline Analyzes Bug Sees New Its OwnFails Failure Ticket Ticket FailureSolution: Label-Based Cycle Prevention▸ PFA-created tickets receive no-autofix label at creation time▸ Autofix's query excludes tickets with no-autofix label▸ Cycle is broken at the state machine level, not by detection heuristics▸ Formal property: the label graph is a DAG, not a cycle▸ Same pattern applies to any self-referential automation chain14
Show transcript for slide 15
III. ROBUSTNESSAction Space Reduction via SkillsSkills as structured constraints that reduce the agent's effective action spaceUnconstrained Agent Skill-Constrained Agent▸ Action space: all possible tool call sequences ▸ Action space: task-specific instruction set▸ High variance in output quality ▸ Structured verdict: declare intent before acting▸ Harder to review (anything could happen) ▸ Reviewable: expected behavior is documented▸ Security surface: entire tool set ▸ Security surface: scoped to task requirementsAnalogy: type systems for agentsSkills function like type signatures: they constrain the space of valid behaviors without dictating implementation. A/B testing of skillvariants (our production approach) is analogous to benchmarking type system designs for ergonomics and correctness tradeoffs.15
Show transcript for slide 16
IV. MEASUREMENTMeasuring AI Agent ProductivityNaive Metrics (misleading) Better Metrics (still imperfect)▸ MRs merged per week (quantity, not quality) ▸ Review acceptance rate (% merged without revision)▸ Lines of code changed (Goodhart's law) ▸ Engineer time displaced (hours saved per task)▸ Time to first MR (ignores review cost) ▸ Defect escape rate (bugs introduced by agent)▸ Bug close rate (includes false closures) ▸ Cost per merged MR (tokens + review time)The Measurement ParadoxIf agents handle the easy bugs, engineers handle the hard ones. Average bug resolution time may INCREASE becausethe easy bugs no longer pull down the average. Productivity improvements are real but invisible in aggregate metrics.You need cohort analysis: compare similar-difficulty tasks with and without agent assistance.16
Show transcript for slide 17
IV. MEASUREMENTAutomation Bias and Over-Reliance▸ Automation bias: tendency to favor suggestions from automated systems▸ Particularly dangerous in code review: AI says it's fine, reviewer agrees faster▸ Complacency effect increases with perceived agent reliability▸ The 'LGTM stamp' risk: human review degrades when agent review exists▸ Ironically, better agents may produce worse human review qualityCountermeasures▸ Agent never self-merges: humans must take an explicit action▸ AI review complements, does not replace, human review assignment▸ Chill mode: suppress low-severity findings to prevent review fatigue▸ Defect injection testing: periodically verify human reviewers catch planted bugs17
Show transcript for slide 18
IV. MEASUREMENTHuman-in-the-Loop as Supervisory ControlControl Theory Mapping Why Human Supervision Matters▸ Plant: the codebase + CI pipeline ▸ The controller is stochastic: identical inputs may▸ Controller: AI agent (non-linear, stochastic) produce different outputs▸ Sensor: test suites, linters, gate output ▸ No Lyapunov function exists for LLM reasoning (stabilityis not provable)▸ Actuator: git push, MR creation ▸ Test suites are incomplete sensors (cannot observe all▸ Supervisor: human reviewer (override authority) state)▸ Reference signal: correct, secure, passing code ▸ Human acts as a bounded-rationality supervisor withoverride authority▸ The merge button is a hard gate, not a suggestion18
Show transcript for slide 19
V. EVIDENCEProduction Evidence at ScaleCase Study: Red Hat Agentic Ecosystems production data (2025-2026)100+ 7 15+ 5MRs merged Production Maintained Engineers onper week workflows projects the squadWorkflows: Autofix (triage + fix), Code Review, Knowledge Sync, Package Onboarding (CPU/CUDA/ROCm/Gaudi/TPU/Neuron/Spyre),Pipeline Failure Analyzer, RFE Assessor, Security Alerts. Zero security incidents from agent-generated code to date.19
Show transcript for slide 20
V. OPEN PROBLEMSOpen Research ProblemsFormal Verification of Agent BehaviorCan we develop tractable verification for bounded agent traces? Partial verification of finite tool-call sequences may be feasible even ifgeneral verification is not.Prompt Injection DefensesNo complete defense exists. Research directions: instruction hierarchy enforcement, data tainting through attention layers, formal separationof instruction and data channels in transformer architectures.Alignment in CI/CDAgent 'values' are shaped by training data and prompts. How do you align agent behavior with organizational security policies when thosepolicies can't be fully specified in natural language?Optimal Human-Agent Task AllocationWhich tasks should be delegated and which kept human? Current allocation is heuristic. We lack formal frameworks for delegation decisionsunder uncertainty.20
Show transcript for slide 21
Key Takeaways▸ AI agents are confused deputies: ambient authority + untrusted input▸ Prompt injection is fundamentally different from prior injection classes▸ Kernel-level containment is the only trustworthy security boundary▸ Non-determinism requires statistical thinking, not deterministic proofs▸ Human-in-the-loop is supervisory control, not a crutch▸ The defense stack must be ordered by enforceability, not convenience▸ Measure displaced effort, not output volume21
Show transcript for slide 22
Questions? linkedin.com/company/red-hatyoutube.com/@redhatAndre Lustosa, PhD | alustosa@redhat.comhttps://www.redhat.com/en/products/aifacebook.com/redhatx.com/RedHat22
Keyboard: Left/Right or Page Up/Page Down · Space advances · Shift + Space goes back · Home/End jump to the first or last slide.