Chained coding automations need authority lineage as well as credit limits

The trigger surface expands

GitHub’s 28 October changelog adds three kinds of reach to Copilot Automations. External systems can start a run through an API; 24 additional repository events can act as triggers; and one automation can trigger another after success or failure. The release also adds 20 GitHub tools, connections to selected custom MCP tools and optional AI-credit limits per run, day, week or month.

These are useful operating primitives. They also turn a single saved prompt into a chain whose authority can cross system, repository and action boundaries. An incident ticket may start triage, triage may open a pull request, the pull request may trigger review, and a review outcome may start a merge or deployment step. Each transition can be individually configured while the combined path remains difficult to see.

Cost is not authority

Credit limits answer how much an automation may consume. A per-run limit can stop one session at its threshold; longer-period limits prevent new runs after the budget is exhausted. Neither control says whether a triggering identity was trusted for the downstream action, whether the context was altered, or whether an upstream agent is allowed to satisfy a trigger intended for a person.

GitHub documents a separate “Can be triggered by” choice. Its safer default is people only; administrators can permit users and Copilot so agent-created events start another automation. Tool selection then bounds what each stage can do. Existing review protections still matter: for example, an automation-created pull request cannot approve itself, and workflows may require a person with write access before they run.

The Verge’s product coverage confirms that reusable automations are part of the broader Copilot app update. It does not independently test chained failure modes. The evidence therefore supports a control-design response, not a claim that the feature is insecure.

Add a transition receipt

For each edge in a chain, store a compact receipt: automation ID and revision, trigger type, originating actor class, source event ID, repository, tools enabled, input-context hash, output artifact, budget consumed and next-stage decision. The downstream stage should evaluate the receipt before acting. A success event is not proof that the upstream stage was authorised for the next operation.

Make human and agent triggers visibly different. If a stage can accept both, define whether they receive the same tools and whether approval can be inherited. Do not let an agent-created label or comment impersonate a human gate. For external API triggers, authenticate the caller, verify freshness and bind the payload to the intended repository and automation revision.

Exercise failure paths

Test more than the happy path. Replay duplicate webhooks, reordered events, a failed stage that still produces an artifact, a budget exhausted halfway through a write, and an upstream automation that changes after the downstream stage is approved. Confirm that retries are idempotent and that a stopped run cannot leave an ambiguous partial state.

The control should also constrain blast radius. Start with read-only tools, a test repository and explicit branch protections. Add one write tool at a time. Keep merge, review dismissal and workflow retry behind a named approval until evidence shows the narrower chain is stable.

The acceptance record should name which failures leave no state change, which create a recoverable draft and which require manual repair. That classification turns a generic retry policy into an operational response and gives maintainers a clear point at which automation must stop.

Decision rule

Do not enable agent-to-agent triggers merely because every stage has a credit ceiling. Require an end-to-end authority graph and a transition receipt that the next stage can validate. If trigger origin or tool scope cannot be reconstructed after the run, keep the chain people-only. This operationalises the transition checks described in the agent permission matrix.