AI SDLC Certification Prep: Designing Safe Agent Workflows in GitHub

• Map agent responsibilities to the SDLC
• Define architectural boundaries
• Define inputs, outputs, and success criteria
  • Example task contract: vulnerability remediation
• Use CI validation as an enforceable success signal
• Separate planning, execution, and validation
• Plan-first vs plan-plus-execution
  • Option A: plan-first pull request
  • Option B: plan and execution in the same pull request
• Enforce planning boundaries
• Pull requests as architectural control points
• PR template for structured plans
• Plan gate workflow
• CODEOWNERS for sensitive paths
• Design autonomy by risk
• Gate high-risk execution with environments
• Treat workflow outputs as contracts
• Add defensive workflow gating
• Evidence and reliability
• Exam checklist

Reliable agent systems are designed around clear lifecycle boundaries. Instead of treating an agent like a general-purpose developer across the entire SDLC, map its responsibilities to specific stages where GitHub can enforce review, validation, and traceability.

This second post focuses on SDLC mapping, task contracts, planning boundaries, PR governance, workflow outputs, and evidence.

Map agent responsibilities to the SDLC

Agent systems should not operate across the entire SDLC without restriction. When an agent is treated like a general-purpose developer, it becomes harder to reason about its behavior, limit its impact, or audit outcomes.

A better starting point is to scope agents to lifecycle stages where GitHub provides natural control points.

Most teams should start by scoping agents to implementation and validation, where pull requests and workflows provide natural enforcement points.

Define architectural boundaries

Use architectural boundaries to reduce blast radius and improve auditability:

• Scope agents early by path, task type, and permission.
• Treat workflow and infrastructure changes as higher risk than application code changes.
• Prefer PR-based work even for automation.
• Avoid direct-to-default-branch changes.

A common design boundary is: agents propose; humans and policy accept. The agent can prepare work and submit it through a pull request, but repository policy and human reviewers decide whether that work is merged or deployed.

Define inputs, outputs, and success criteria

Each agent task should be defined as a small contract.

When tasks are underspecified, agents can produce changes that look plausible but do not solve the underlying problem.

Example task contract: vulnerability remediation

Inputs

• A security alert or issue link describing the vulnerability.
• Repository scope: changes allowed under src/ and dependency files, but not infra/ unless explicitly requested.
• Constraints: no workflow changes without platform review, no secrets introduced, and no direct-to-main pushes.

Outputs

• A pull request containing:
  • a structured plan in the PR description or .github/pull_request_template.md,
  • a bounded changeset on an agent branch, and
  • evidence links to workflow runs.

Success criteria

• Required checks pass: build, test, and lint.
• The security signal is resolved, such as replacing the vulnerable version.
• Scope matches intent, with no unexpected files changed.
• A rollback or escalation path is recorded for higher-risk changes.

Use CI validation as an enforceable success signal

The following workflow shows how success criteria can become required checks.

name: CI Validation

on:
  pull_request:
    branches: [main]

permissions:
  contents: read
  security-events: write

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

  security-analysis:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Initialize analysis
        uses: github/codeql-action/init@v3
      - name: Analyze
        uses: github/codeql-action/analyze@v3

Repository administrators can then mark these jobs as required status checks using rulesets or branch protection.

Separate planning, execution, and validation

Reliable agent systems separate three things:

• Planning: what will be done and why.
• Execution: the concrete changes made to the repository.
• Validation: evidence that the outcome meets success criteria.

When planning and execution are mixed together, reviewers see only the final diff. They lose the ability to validate intent early, detect misunderstandings, and control scope before impact.

GitHub supports this separation naturally:

Plan-first vs plan-plus-execution

Teams must decide when human validation is required relative to code generation.

Option A: plan-first pull request

In this approach, planning is completed and approved before code changes are introduced.

1. A plan is generated from an issue or agent session.
2. The agent opens a pull request containing only the plan.
3. Reviewers discuss, refine, and approve the plan.
4. After approval, implementation happens in follow-up commits or a new PR.

This creates a clear separation between intent and execution. It is best for high-risk work such as workflows, infrastructure, authentication, authorization, production systems, or security-sensitive areas.

Option B: plan and execution in the same pull request

In this approach, planning and code changes appear in the same PR.

1. The agent opens a PR with a structured plan in the description.
2. Initial code changes are included as commits.
3. The PR continues to evolve as checks and review feedback arrive.
4. Required checks, CODEOWNERS reviews, and branch protections prevent merge until requirements are satisfied.

This approach is useful for lower-risk, easily reversible work where speed and iteration matter.

Enforce planning boundaries

Planning boundaries should be enforced through capability limits, not only instructions.

• Planning agents should use read-only tools.
• Execution should occur only after explicit transition or handoff.
• Automated orchestrators should keep planning read-only and enable write tools only after the plan is accepted.
• Tool allowlists and gates are stronger enforcement than instructions that merely say “do not edit.”

Pull requests as architectural control points

Pull requests are not only collaboration tools. In agent workflows, they are architectural control points.

A common safe workflow is:

1. Agent creates a branch.
2. Agent opens a pull request with a plan.
3. Required reviews validate the approach.
4. GitHub Actions run required checks.
5. Checks pass and approvals complete.
6. The pull request can be merged.

This structure ensures execution is gated by both automation and human review.

PR template for structured plans

A pull request template can require consistent plan and evidence sections.

<!-- File: .github/pull_request_template.md -->

## Plan (required)

- **Goal:**
- **Scope (paths/files):**
- **Steps:**
  1.
  2.
  3.
- **Success criteria (verifiable):**
  - [ ] Required checks pass
  - [ ] Security signals reviewed, if applicable
- **Risks and mitigations:**
- **Rollback / escalation plan:**

## Evidence

- Workflow run(s):
- Scan results, if applicable:

## Review checklist

- [ ] Plan reviewed and approved
- [ ] Required reviews satisfied
- [ ] Required checks satisfied

Plan gate workflow

Templates create consistency, but checks create enforcement.

# File: .github/workflows/plan-gate.yml
name: Plan Gate

on:
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  require-plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Require PR template
        run: |
          if [ ! -f ".github/pull_request_template.md" ]; then
            echo ".github/pull_request_template.md is required."
            exit 1
          fi
          echo ".github/pull_request_template.md found."

A repository administrator can mark this as a required status check so PRs cannot merge unless the governance expectation is satisfied.

CODEOWNERS for sensitive paths

CODEOWNERS routes sensitive changes to the right reviewers.

# File: CODEOWNERS
/security/          @security-team
/.github/workflows/ @platform-team
/infra/             @platform-team
*                   @core-team

This is especially important for small diffs with large consequences, such as workflow, infrastructure, security, or deployment changes.

Design autonomy by risk

Autonomy must be designed, not assumed.

Gate high-risk execution with environments

GitHub environments provide a strong control point for deployments and access to protected secrets.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
    steps:
      - run: echo "Deploying to production..."

If the environment requires reviewers, the job pauses until approval is granted.

Treat workflow outputs as contracts

When a workflow generates data consumed by later steps or jobs, treat that data as an explicit output instead of burying it in logs.

Step outputs pass values between steps in the same job:

steps:
  - id: generate_plan
    run: echo "plan=high level steps" >> "$GITHUB_OUTPUT"

  - run: echo "Plan: $"

Job outputs pass values across jobs:

jobs:
  plan:
    runs-on: ubuntu-latest
    outputs:
      plan: $
    steps:
      - id: generate_plan
        run: echo "plan=high level steps" >> "$GITHUB_OUTPUT"

  implement:
    runs-on: ubuntu-latest
    needs: plan
    steps:
      - run: echo "Using plan: $"

Use the right context for the right purpose:

• github.* for event metadata and runtime decisions.
• vars.* for centrally managed reusable configuration.
• env.* for job-level environment variables and runtime configuration.

Add defensive workflow gating

Even when a workflow is intended for pull requests, repositories often have multiple triggers. Add defensive conditions so PR-specific logic does not run without PR context.

name: PR Validation

on:
  pull_request:
    branches: [main]
  workflow_dispatch:

jobs:
  validate-pr:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test
      - name: Comment on PR
        run: echo "Validation complete"

Workflow reliability improves when plans and signals are treated as structured outputs and guarded by event-aware logic.

Evidence and reliability

An agent system should produce visible artifacts for every meaningful action.

Minimum observability should include:

• a visible plan artifact,
• a bounded pull request and commit history,
• workflow run links for required checks,
• durable artifacts such as logs, reports, or traces, and
• review outcomes and approvals.

Upload artifacts where they are produced and download them where they are reviewed or deployed.

- name: Upload test results
  uses: actions/upload-artifact@v4
  with:
    name: test-results
    path: results/

Reliable systems assume failure. If a required check fails, the agent may revise the PR branch and rerun checks. If the same required check fails twice, escalate to a human reviewer with what failed, what was attempted, what evidence exists, and the suggested next step.

Exam checklist

Remember these points for the certification exam:

• Map agent responsibilities to SDLC stages and GitHub artifacts.
• Define task inputs, outputs, constraints, and success criteria.
• Separate planning, execution, and validation.
• Use plan-first workflows for high-risk changes.
• Use PR templates, required checks, CODEOWNERS, and environments as governance controls.
• Treat outputs and artifacts as workflow contracts.
• Add defensive gating for PR-only behavior.
• Escalate after repeated validation failures.

In the next post, we will look at how GitHub agents interact with APIs, workflows, MCP servers, registries, allow lists, and execution boundaries.