Safe Delegation Boundaries: How Platform Teams Can Wire AI Coding Assistants Into CI/CD Without Losing Control

The attack described by Matthew Green has a clean two-part structure: a payload that hijacks an agent, and a delivery mechanism where the hijacked agent carries that payload to the next agent in line. What makes this particularly sharp for CI/CD contexts is that the delivery mechanism doesn't require network access or direct agent-to-agent communication — a shared package cache is enough, because one agent writes it and another trusts it. In a typical TypeScript monorepo pipeline, your AI coding assistant might write an updated `package-lock.json` or resolve a dependency during a PR build; if a downstream agent consumes that lockfile without verifying its provenance, you have the propagation path. The fix isn't to disable the cache — it's to treat every artifact an agent produces as untrusted until it passes a provenance check, and to enforce write-only or scoped permissions so no agent can read back what another agent wrote without an explicit trust boundary in between. Source: [Quoting Matthew Green] — simonwillison.net (https://simonwillison.net/2026/Oct/1/matthew-green/).

// Artifact provenance check before any agent consumes a shared cache entry
import { createHash } from 'crypto';
import { readFileSync, writeFileSync } from 'fs';

interface ProvenanceRecord {
  agentId: string;
  runId: string;
  artifactHash: string;
  timestamp: string;
  signature: string; // HMAC with pipeline secret
}

function verifyArtifactProvenance(
  artifactPath: string,
  record: ProvenanceRecord,
  pipelineSecret: string
): boolean {
  const content = readFileSync(artifactPath);
  const actualHash = createHash('sha256').update(content).digest('hex');

  if (actualHash !== record.artifactHash) {
    throw new Error(`Artifact hash mismatch — possible cache poisoning: ${artifactPath}`);
  }

  const expectedSig = createHash('sha256')
    .update(`${record.agentId}:${record.runId}:${record.artifactHash}:${record.timestamp}:${pipelineSecret}`)
    .digest('hex');

  return expectedSig === record.signature;
}

The core insight here is that an AI coding assistant embedded in a CI/CD pipeline is itself a system under development — it has its own capability envelope, its own failure modes, and its own evaluation cadence. When you treat it as just another pipeline step, you lose the separation needed to ask 'did the agent change, or did the application requirements change?' which is exactly the question you need to answer when a regression surfaces. The ADLC framework argues for explicit shared requirements and evaluation cases that bridge the two lifecycles at defined integration points rather than letting them blur together. For a platform team, this translates to versioning your agent configuration and prompts separately from your application code, running agent-specific evaluation suites in parallel with application tests, and requiring an explicit promotion gate before an updated agent version is trusted with production-bound changes. Source: [Where the Agent Development Lifecycle Fits] — towardsdatascience.com (https://towardsdatascience.com/where-the-agent-development-lifecycle-fits/).

// Versioned agent configuration — kept separate from application code
interface AgentConfig {
  version: string;
  model: string;
  allowedTools: string[];
  maxAutonomousChanges: number; // lines of code before human review required
  scopeConstraints: {
    allowedPaths: string[];
    blockedPaths: string[];
    requiresApprovalPatterns: RegExp[];
  };
}

const codingAssistantConfig: AgentConfig = {
  version: '2.1.0',
  model: 'claude-3-5-sonnet',
  allowedTools: ['read_file', 'write_file', 'run_tests', 'lint'],
  maxAutonomousChanges: 50,
  scopeConstraints: {
    allowedPaths: ['src/', 'tests/'],
    blockedPaths: ['.github/', 'infrastructure/', 'scripts/deploy'],
    requiresApprovalPatterns: [/package\.json$/, /tsconfig.*\.json$/, /\.env.*/]
  }
};

// Evaluated independently before being promoted into pipeline
async function evaluateAgentConfigPromotion(
  config: AgentConfig,
  evalSuiteResults: EvalResult[]
): Promise<PromotionDecision> {
  const passRate = evalSuiteResults.filter(r => r.passed).length / evalSuiteResults.length;
  if (passRate < 0.95) {
    return { approved: false, reason: `Eval pass rate ${passRate} below threshold` };
  }
  return { approved: true, configVersion: config.version };
}

The CrewAI analysis of the enterprise ROI gap is essentially describing a trust boundary problem wearing the costume of a data access problem. When an AI coding assistant in your pipeline needs to understand your PostgreSQL schema to generate a migration, or needs to read your existing TypeScript interfaces to generate consistent types, the failure mode isn't usually that the agent is incapable — it's that the agent is making decisions based on partial context, producing outputs that are syntactically correct but semantically wrong for your specific codebase. The fix is to co-locate agents with the data they need at design time, not to give them broader read access at runtime. This means building agent-specific context bundles — curated snapshots of schema, interface definitions, and architectural constraints — that travel with the agent invocation rather than being fetched opportunistically. Source: [How to build Agents Where Data Already Lives] — blog.crewai.com (https://blog.crewai.com/how-to-build-agents-where-data-already-lives/). [AI Synthesis] This pattern also directly addresses the ADLC separation concern: when context is explicit and versioned, you can evaluate whether an agent is working with the right context before it touches production-bound code, which is a much stronger safety property than trusting the agent to fetch what it needs.

// Context bundle — assembled at invocation time, not fetched by the agent
interface AgentContextBundle {
  schemaSnapshot: string;       // pg_dump --schema-only, specific tables only
  relevantInterfaces: string[]; // TypeScript interfaces the agent may touch
  architecturalConstraints: string; // pulled from ADR markdown, curated
  recentChangelog: string[];    // last 10 commits touching affected files
  bundleVersion: string;
  assembledAt: string;
}

async function assembleContextBundle(
  prChangedFiles: string[],
  repoPath: string
): Promise<AgentContextBundle> {
  const affectedSchemas = await inferAffectedSchemas(prChangedFiles);
  const interfaces = await extractRelevantInterfaces(prChangedFiles, repoPath);
  const constraints = await loadArchitecturalConstraints(prChangedFiles, repoPath);

  return {
    schemaSnapshot: await dumpScopedSchema(affectedSchemas),
    relevantInterfaces: interfaces,
    architecturalConstraints: constraints,
    recentChangelog: await getRecentChangelog(prChangedFiles, 10),
    bundleVersion: computeBundleHash({ affectedSchemas, interfaces, constraints }),
    assembledAt: new Date().toISOString()
  };
}

Google's federated learning work with TEEs introduces four principles — data minimization, anonymization, transparency, and verifiability — and the last two are the ones that matter most for agentic CI/CD governance. Transparency here means the authorized workload is defined before execution and cannot be changed at runtime; verifiability means a third party can confirm what ran. Today's CI/CD agent integrations offer neither: you can inspect logs after the fact, but you can't prove the agent ran the approved config and only touched the scoped data. The TEE model suggests a near-term architecture where agent execution happens inside an attested enclave, with the invocation manifest (model version, tool list, data scope) signed before execution and the execution result accompanied by a remote attestation report. This is not production-ready today for most cloud-native stacks, but the pattern is clearly where strong governance requirements will push platform teams — especially in regulated industries where 'an AI wrote this code' needs an audit trail as strong as any other change control. Source: [Toward provably private learning from federated data] — research.google (https://research.google/blog/toward-provably-private-learning-from-federated-data/).

// Minimal attestation record attached to every agent-generated commit
interface AgentAttestationRecord {
  agentConfigVersion: string;
  modelId: string;
  toolsUsed: string[];
  dataScope: {
    filesRead: string[];
    filesWritten: string[];
    externalCallsMade: string[];
  };
  executionHash: string;    // hash of (config + inputs + outputs)
  attestationToken?: string; // TEE-issued token when available
  humanReviewRequired: boolean;
  reviewReason?: string;
}

// Committed as .github/agent-provenance/<commit-sha>.json
async function attachProvenanceToCommit(
  commitSha: string,
  record: AgentAttestationRecord
): Promise<void> {
  const provenancePath = `.github/agent-provenance/${commitSha}.json`;
  const signed = signRecord(record, process.env.PIPELINE_SIGNING_KEY!);
  await writeFile(provenancePath, JSON.stringify(signed, null, 2));
  // Fail the pipeline if humanReviewRequired and no review token present
  if (record.humanReviewRequired && !process.env.HUMAN_REVIEW_TOKEN) {
    throw new Error(`Commit ${commitSha} requires human review before merge`);
  }
}

The 'death of coding by hand' debate, reignited by the Rails creator's comments, tends to flatten what is actually a nuanced engineering governance question into a binary about human versus machine authorship. For a platform team building a real CI/CD integration, the more precise question is: what is the shape of decisions your AI coding assistant will encounter, and which of those require architectural context that isn't capturable in a prompt or a context bundle? The answer is almost always: interface contracts between services, schema evolution under active traffic, and anything that touches a security boundary. These are the places where the agent should be wired to stop, produce a structured question, and wait — not because the model can't generate a plausible answer, but because the right answer depends on organizational context that changes faster than any context bundle can track. Source: [The Pulse: RoR creator sparks new 'death of coding by hand' debate] — blog.pragmaticengineer.com (https://blog.pragmaticengineer.com/the-pulse-ror-creator-sparks-new-death-of-coding-by-hand-debate/). [AI Synthesis] This connects directly to the ADLC separation point: when agent capability boundaries are explicit and versioned, you can define escalation triggers as part of the agent's configuration rather than hoping the model infers them from the prompt — which is the difference between a governance property you can audit and one you have to take on faith.

// Escalation trigger classification — part of agent config, not the prompt
type DecisionCategory = 'routine' | 'moderate' | 'high' | 'critical';

interface EscalationRule {
  pattern: RegExp | ((filePath: string, diff: string) => boolean);
  category: DecisionCategory;
  reason: string;
}

const escalationRules: EscalationRule[] = [
  {
    pattern: /\.migration\.(ts|sql)$/,
    category: 'high',
    reason: 'Schema migrations require DBA review under active traffic'
  },
  {
    pattern: (_, diff) => diff.includes('export interface') && diff.includes('-'),
    category: 'high',
    reason: 'Possible breaking change to exported interface contract'
  },
  {
    pattern: /(auth|jwt|crypto|password|secret|token)/i,
    category: 'critical',
    reason: 'Security-relevant code path — mandatory human review'
  },
  {
    pattern: /package\.json$/,
    category: 'moderate',
    reason: 'Dependency changes logged for provenance'
  }
];

function classifyDecision(filePath: string, diff: string): EscalationRule | null {
  return escalationRules
    .sort((a, b) => ['critical','high','moderate','routine'].indexOf(a.category)
      - ['critical','high','moderate','routine'].indexOf(b.category))
    .find(rule => typeof rule.pattern === 'function'
      ? rule.pattern(filePath, diff)
      : rule.pattern.test(filePath)) ?? null;
}