DevSecOps Reference [2026]: Agentic Pipeline Rules

Agentic delivery systems changed the threat model. A modern pipeline is no longer just source to build to deploy; it is prompt to tool invocation to generated diff to policy gate to signed release. That means every autonomous action needs the same controls security teams already expect from human-driven CI, plus stronger identity, provenance, and data-boundary checks.

This reference is optimized for breadth. Use it as a build sheet for platform teams, security engineers, and AI tooling owners who need a minimum mandatory baseline for agent-enabled software delivery. If your workflow handles production records, redact sensitive fields before logs, prompts, or fixtures with TechBytes’ Data Masking Tool. Generated patches and snippets can then be normalized before review with the Code Formatter.

The Short Version

For agentic pipelines, the mandatory baseline is simple: scan early, authenticate every actor, sign every artifact, attach provenance, enforce policy on release, and isolate the data an agent can read or mutate.

Why This Reference Exists

The core failure mode in agentic workflows is not just vulnerable code. It is unchecked automation: an agent reading too much, writing too much, shipping without review, or interacting with tools outside policy. The 2026 baseline therefore centers on five enforcement layers:

Identity: workload identity, short-lived credentials, and human approval boundaries.
Code and dependency analysis: static analysis, secret scanning, container scanning, and license checks.
Supply-chain integrity: SBOM, provenance, signed artifacts, and verifiable release metadata.
Runtime and environment controls: scoped permissions, sandboxing, and deploy-time policy.
Agent-specific safeguards: prompt logging boundaries, tool allowlists, redaction, and action approval tiers.

Mandatory Controls

1. Pre-merge controls

Block leaked credentials with Gitleaks or equivalent secret detectors.
Run language-aware static analysis such as CodeQL and Semgrep.
Generate dependency inventory and license data on every merge candidate.
Require human review when an agent edits deployment code, IAM, networking, billing, or data-access paths.

2. Build controls

Build in ephemeral runners with short-lived identity.
Emit SBOM documents in a standard format such as SPDX or CycloneDX.
Sign artifacts with Cosign and store attestations alongside releases.
Attach provenance using in-toto or equivalent build attestation metadata.

3. Release controls

Fail release if critical vulnerabilities exceed policy.
Reject unsigned images, packages, or missing provenance.
Evaluate release policy with OPA, admission control, or environment-specific rules.
Restrict production deploy permissions to approved workflows only.

4. Agent-specific controls

Use tool allowlists per task class.
Separate read, write, and execute scopes for each agent role.
Mask secrets and customer data before prompt submission, trace storage, and eval datasets.
Store action logs so every generated change can be traced to input, tool call, and reviewer.

Keyboard Shortcuts

Reference pages are more useful when they behave like tooling. Use these conventions if you ship an internal DevSecOps portal or runbook UI for agentic pipelines.

Shortcut	Action	Why it matters
/	Focus command search	Fast filtering during incident response.
g then c	Jump to commands	Useful for operators who already know the control they want.
g then f	Jump to configuration	Reduces friction when tuning policy.
Shift + ?	Open shortcut help	Good default for reference-heavy docs.
c	Copy active code block	Matches terminal-first workflows.

Commands by Purpose

Use the live filter below to narrow commands by scanner, supply chain, policy, runtime, or agent controls.

Live search

Secret scanning

gitleaks detect --source . --redact --exit-code 1

pre-commit run --all-files

Static and dependency analysis

semgrep ci

trivy fs --scanners vuln,secret,license .

SBOM and signing

syft packages dir:. -o cyclonedx-json > sbom.json

cosign sign --yes ghcr.io/acme/app:build-${GITHUB_SHA}

cosign attest --yes --predicate provenance.json ghcr.io/acme/app:build-${GITHUB_SHA}

Policy and runtime checks

conftest test deployment.yaml --policy policy/

cosign verify ghcr.io/acme/app:build-${GITHUB_SHA}

Agent workflow controls

agentctl run --task patch --sandbox workspace-write --approval on-request --allow git,rg,pytest

masker redact --input eval-fixtures.json --output eval-fixtures.masked.json

Configuration

The baseline configuration below is intentionally opinionated: fail closed on secrets, enforce artifact signing, and isolate privileged deploy steps from general agent execution.

pipeline:
  security:
    secrets_scan: required
    sast:
      tools: [semgrep, codeql]
      fail_on: high
    dependencies:
      sbom: cyclonedx
      vuln_scan: required
      license_policy: enforce
    supply_chain:
      sign_artifacts: true
      attest_provenance: true
      verify_before_release: true
  agent_controls:
    prompt_redaction: required
    tool_allowlist:
      default: [git, rg, npm, pytest]
      privileged: [terraform, kubectl]
    approval_tiers:
      low_risk: auto
      medium_risk: reviewer
      high_risk: two_person
    writable_paths:
      - src/
      - tests/
    blocked_targets:
      - infra/prod/
      - secrets/
      - billing/
  deploy:
    production:
      requires_signed_artifact: true
      requires_policy_pass: true
      requires_human_approval: true

Three details matter most. First, keep the agent tool allowlist narrower than the human engineer toolset. Second, treat production infrastructure paths as high-risk by default. Third, separate generation jobs from release jobs so untrusted output cannot publish itself.

Advanced Usage

Use risk tiers instead of one universal approval rule

Agentic systems break when every task has the same permission model. A documentation edit, a refactor in an isolated package, and a change to network policy should not move through the same control path. Mature teams classify tasks into low, medium, and high-risk buckets and apply different review and execution boundaries.

Attach provenance to generated diffs, not just build artifacts

Supply-chain integrity is stronger when the generated code change itself carries metadata about which model, tools, repository state, and policy version produced it. That makes later incident review much faster and narrows blast radius during rollbacks.

Run security evaluations against the agent, not just the app

Test prompt injection handling, forbidden tool attempts, path traversal attempts, secret exfiltration prompts, and policy bypass scenarios. These are control-plane tests for the automation layer. In practice, they are as important as unit tests for the application.

Prefer benchmark families that map to operational risk

Useful benchmark categories include remediation time for blocked secrets, percentage of signed releases, mean time to revoke compromised credentials, policy false-positive rate, and agent task completion under least privilege. These measures outperform vanity metrics such as total scans per day.

security_kpis:
  signed_release_rate_target: 100%
  secret_block_sla: 15m
  critical_vuln_release_exceptions: 0
  policy_false_positive_rate_target: < 3%
  masked_prompt_coverage_target: 100%

A final implementation note: if your reference portal includes client-side search and copy actions, keep the JavaScript small and auditable. Reference pages should help operators move faster without becoming another opaque UI layer.