# Software delivery & supply chain: enterprise AI policy pack Allow code generation and delivery automation while preserving review, provenance, protected branches, release authority and build-system integrity. Implementation guidance, not executable Tracelet configuration or legal advice. Tool names identify places where the control may apply; they do not claim shipped connector coverage. Confirm actual tool/action coverage and enforce destination permissions. Replace example thresholds, IDs and approval windows with your approved values. ## Control scope - Protected assets: Source repositories, CI workflows, build identities, packages, images and release environments - Consequential actions: Protection bypass, workflow privilege change, artifact publication, secret exposure and production deploy - Applicable systems: GitHub, GitLab, Bitbucket, CI platforms, package registries, container registries and deployment systems - Context to resolve: Resolve repository, branch, commit, diff, workflow permissions, dependency provenance, artifact digest, environment and release approver. - Enforcement boundary: Repository rules, environment protection, isolated builders, registry permissions and deploy identities are authoritative. Agent policy adds intent and context before those boundaries. ## Owners Developer platform owner + application security ## Configure first - Protected repositories, branches, release environments, registries and production deploy targets - Required checks, reviewers, trusted builders, signing identities and provenance requirements - High-risk CI permissions, third-party action policy and emergency rollback workflow ## Shared decision baseline ### Resolve the real target Decide on immutable IDs and effective context: principal, tenant/account, environment, resource, data classification and destination. Names and local profiles are hints, not authority. ### Fail closed on consequential ambiguity If the target, blast radius, tenant or data classification cannot be resolved, hold the action. Do not treat missing metadata as non-production or low risk. ### Bind approval to the exact action An approval covers the actor, operation, target set, content or artifact digest, value and expiry. Material changes invalidate it; the requester cannot approve their own action. ### Keep an evidence-grade decision record Record resolved context, policy version, matched rule, decision, approver and downstream result. Minimise captured sensitive content and protect the record from the acting identity. ## Policies ### SW-01: Block bypass or removal of protected-branch controls - Severity: Critical - Decision: Block - Owner: Repository owner #### Policy statement Deny agent actions that remove or bypass required reviews, status checks, signed commits, merge queue, force-push protection or restricted deletion on protected repositories and branches. #### Covered operations - Delete or weaken branch/ruleset protection - Force push or direct push to protected branch - Dismiss reviews or bypass required checks - Delete protected release branch or tag #### Evaluation rules - Resolve repository ID, branch/tag, applicable inherited ruleset and bypass actor from the destination API. - Compare resulting protection strength and detect equivalent bypass via custom roles, apps or temporary rule disablement. - Do not allow the code-writing agent to add itself or its app to a bypass list. #### Example decisions (illustrative; do not run against live systems) - **GitHub:** `Add the agent app to the main ruleset bypass list`. Block. - **GitLab:** `Force-push generated changes directly to the protected release branch`. Block. #### Applicable tools and systems - GitHub - GitLab - Bitbucket - Azure DevOps Repos - Gerrit #### Enforcement Use organisation-owned repository rulesets and app permissions that cannot administer protection. Require changes through pull/merge requests and destination-native checks. #### Exception / approval A human incident owner may use a destination-native, logged bypass when configured; the coding agent cannot hold reusable bypass authority. #### Test fixtures - Should remain permitted: Create a feature branch and open a pull request that is subject to all required checks. - Should be blocked or held: Disable the ruleset, self-add to bypass, dismiss a required review or force-push to the protected branch. #### Implementation references - [GitHub · About rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) ### SW-02: Review CI changes that expand code-execution privilege - Severity: Critical - Decision: Require approval - Owner: CI platform owner + application security #### Policy statement Hold workflow changes that add privileged runners, write tokens, untrusted third-party actions, secret access, production credentials or execution of fork-controlled code. #### Covered operations - Edit CI workflow or runner configuration - Increase token permissions or secret availability - Add/change third-party action, image or remote script - Change environment protection or deploy credentials #### Evaluation rules - Evaluate the workflow diff and effective permissions, events, runner trust, secret flow and pinned dependency provenance. - Require security review for pull-request-triggered workflows that access secrets or write permissions. - Bind approval to commit and workflow digest; later edits invalidate approval. #### Example decisions (illustrative; do not run against live systems) - **GitHub Actions:** `Change permissions: contents: read to contents: write and add pull_request_target`. Hold for security review. - **GitLab CI:** `Run a curl | sh step on a privileged production runner`. Hold. #### Applicable tools and systems - GitHub Actions - GitLab CI - Jenkins - CircleCI - Buildkite - Azure Pipelines - AWS CodeBuild #### Enforcement Protect workflow paths with CODEOWNERS/rulesets, use isolated least-privilege runners and default read-only tokens. Evaluate third-party actions and images by immutable digest. #### Exception / approval Approval covers exact commit, workflow permissions, runner and dependencies. Emergency changes use the protected repository process and remain reviewable. #### Test fixtures - Should remain permitted: Change a test command without altering permissions, events, runner class, secrets or external code sources. - Should be blocked or held: Add write permission after approval, reference a floating untrusted action or expose secrets to fork-controlled code. #### Implementation references - [GitHub · About rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) - [SLSA · Build track requirements](https://slsa.dev/spec/v1.2/requirements) ### SW-03: Block publication of untrusted or untraceable artifacts - Severity: Critical - Decision: Block - Owner: Artifact registry owner #### Policy statement Deny publication or promotion of packages, containers and release artifacts that were not built by an approved builder from a reviewed commit or that fail required signing, provenance, malware and vulnerability policy. #### Covered operations - Publish package or container - Promote artifact to production registry/channel - Replace mutable release tag - Disable signing, provenance or security scan requirement #### Evaluation rules - Resolve artifact digest, source commit, builder identity, provenance, dependency state and scan results. - Decide on immutable digest, not tag or filename. Reject local developer builds for protected publication channels. - Block mutable overwrite of released versions and any attempt to bypass required attestations. #### Example decisions (illustrative; do not run against live systems) - **Container registry:** `Push local image to payments:latest in the production registry`. Block. - **npm / PyPI:** `Publish a package version without the protected release workflow`. Block. #### Applicable tools and systems - GitHub Packages - GitLab Registry - Amazon ECR - Google Artifact Registry - Azure Container Registry - npm - PyPI - JFrog Artifactory #### Enforcement Allow protected publication only from the trusted build identity, verify signed provenance/attestations and make released versions immutable where supported. #### Exception / approval A quarantined emergency artifact still requires known source, digest, independent approval and retrospective completion of evidence before broader promotion. #### Test fixtures - Should remain permitted: Publish a signed artifact from the approved builder with matching commit and passing policy. - Should be blocked or held: Publish from a laptop, reuse a tag for a different digest or omit required provenance/scan evidence. #### Implementation references - [SLSA · Build track requirements](https://slsa.dev/spec/v1.2/requirements) ### SW-04: Approve the exact artifact deployed to production - Severity: Critical - Decision: Require approval - Owner: Production service owner #### Policy statement Hold production deploys and rollbacks unless approval is bound to the immutable artifact digest, target environment, release plan and valid change window. #### Covered operations - Deploy/promote release to production - Rollback to an earlier artifact or database state - Change target environment, region, traffic percentage or release parameters #### Evaluation rules - Verify artifact provenance and map digest to reviewed source commit and passing checks. - Resolve target environment/regions and service owner. Treat rollback as a new consequential action with known compatibility. - Invalidate approval on digest, configuration, migration, target or rollout-strategy changes. #### Example decisions (illustrative; do not run against live systems) - **Argo CD:** `Sync payments-prod to image digest sha256:…`. Hold until that digest and target are approved. - **GitHub Environments:** `Deploy a different artifact after environment approval`. Hold again. #### Applicable tools and systems - GitHub Environments - GitLab Deployments - Argo CD - Flux - Spinnaker - Harness - Kubernetes - Cloud deployment services #### Enforcement Use protected deployment environments and a deploy identity that accepts immutable digests only. Record downstream deployment result and preserve separation between requester and approver. #### Exception / approval Incident rollback requires incident commander approval, exact rollback digest and compatibility evidence; approval expires with the incident window. #### Test fixtures - Should remain permitted: Deploy the exact approved digest to the approved environment during the window. - Should be blocked or held: Change tag/digest, add a region, alter migration inputs or reuse approval for another service. #### Implementation references - [GitHub · Deployment environments](https://docs.github.com/en/actions/reference/deployments-and-environments) - [SLSA · Build track requirements](https://slsa.dev/spec/v1.2/requirements) ### SW-05: Block credential and sensitive-data leakage through delivery systems - Severity: Critical - Decision: Block - Owner: Application security + secrets owner #### Policy statement Deny commits, workflow changes, build output and artifacts that expose live secrets, private keys, tokens or restricted production data. #### Covered operations - Commit or push detected secret - Echo secret to CI log or test report - Upload secret-bearing artifact, cache or debug bundle - Expose production data in fixture or preview environment #### Evaluation rules - Inspect staged diff, generated files, workflow log commands and artifact manifests without retaining full secret values. - Treat encoding, archives and generated outputs as possible disclosure paths. - On a confirmed live secret, block publication and initiate revocation/rotation; deleting the commit alone is insufficient. #### Example decisions (illustrative; do not run against live systems) - **Git:** `Push .env.production containing a live API key`. Block and rotate the credential. - **CI:** `Upload a debug artifact containing a production database dump`. Block. #### Applicable tools and systems - GitHub - GitLab - Bitbucket - CI platforms - Artifact registries - Secret managers - Preview deployment platforms #### Enforcement Combine pre-receive/push protection, CI secret scanning, log masking and artifact DLP. Keep production data out of build identities and revoke exposed credentials through the system of record. #### Exception / approval No disclosure exception. False positives can be reviewed using a fingerprint; live secret values remain prohibited. #### Test fixtures - Should remain permitted: Commit a documented placeholder or secret reference that cannot authenticate. - Should be blocked or held: Encode a live key, expose it in logs or upload a dump through a build artifact or preview deployment. #### Implementation references - [Microsoft Purview · Data loss prevention](https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp) - [SLSA · Build track requirements](https://slsa.dev/spec/v1.2/requirements) ### SW-06: Require human review of agent-authored changes to security-sensitive paths - Severity: High - Decision: Require approval - Owner: Application security + repository owner #### Policy statement Hold merge of any change authored or co-authored by a coding agent that touches authentication, authorisation, cryptography, secrets handling, CI workflows, infrastructure code or dependency manifests until a named human reviewer who did not prompt the agent has approved the exact diff. An agent may not approve, self-merge or dismiss reviews on its own change. #### Covered operations - Open, update or merge a pull request whose commits carry an agent author or co-author - Approve or dismiss a review on a pull request the same agent identity created - Add, remove or upgrade a dependency in a manifest or lockfile through an agent - Change CODEOWNERS, required reviewers or the review policy for a protected path #### Evaluation rules - Resolve the agent identity from commit trailers, the token used and the assistant session; treat a change with no attributable human author as agent-authored. - Match the diff against the protected path set (auth, crypto, secrets, CI, infrastructure, manifests) and hold when any hunk lands in it. - Require the approving reviewer to differ from the person who prompted the agent and from the agent identity; invalidate approval when the diff changes after review. - Hold dependency additions whose package has no verified provenance or was first published recently, and never let the agent resolve a missing package by publishing one. #### Example decisions (illustrative; do not run against live systems) - **GitHub:** `Copilot agent opens a pull request that rewrites the session-token validator and requests review from its prompter`. Hold for a CODEOWNERS reviewer who did not prompt the change. - **GitLab:** `Agent-authored merge request adds a new transitive dependency with no provenance attestation`. Hold until the package is reviewed and pinned. - **Claude Code:** `Agent approves and merges its own change to the deploy workflow`. Block the self-approval; route to a human reviewer. #### Applicable tools and systems - GitHub - GitLab - Bitbucket - GitHub Copilot - Claude Code - Cursor - Codex - Dependabot / Renovate #### Enforcement Use rulesets with required reviewers and CODEOWNERS on protected paths, block self-approval and require provenance checks in CI. The control plane records the agent, session and prompter behind each change and holds merges before the repository rule applies. #### Exception / approval Emergency fixes still require an independent human approval; the reviewer may be paged, but the agent and the prompter cannot approve. #### Test fixtures - Should remain permitted: Merge an agent-authored documentation or test-only change with one human approval, or a protected-path change approved by an independent CODEOWNERS reviewer. - Should be blocked or held: Merge an agent-authored change to the auth module approved only by its prompter, or let the agent dismiss a review and merge its own workflow edit. #### Implementation references - [GitHub · About rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) - [OWASP · LLM03:2025 Supply Chain](https://genai.owasp.org/llmrisk/llm032025-supply-chain/) - [SLSA · Build track requirements](https://slsa.dev/spec/v1.2/requirements) - [npm · Registry signatures and provenance](https://docs.npmjs.com/about-registry-signatures) ## Rollout checklist - [ ] Inventory authoritative resource IDs, environments, classifications and owners. - [ ] Map every entry point: IDE, agent, CLI, MCP, API, browser and direct console. - [ ] Put the hard deny or least-privilege boundary in the destination system. - [ ] Test permitted, held and denied fixtures using synthetic data in a sandbox. - [ ] Test aliases, APIs, batch operations, changed approvals, retries and unknown scope. - [ ] Observe matches, tune false positives and then enforce a bounded production scope. Coverage: https://tracelet.ai/platform#coverage