Agent should require explicit consent before changing workflows that can increase external metered costs

Open 💬 2 comments Opened Aug 27, 2026 by aboozar-droid
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

I am reporting a product/governance issue involving agent behavior with a connected GitHub account and GitHub Actions.

During an ongoing software project, the agent gradually changed the execution strategy so that GitHub Actions became an authoritative full-regression gate. This increased reliance on an external metered service. The change was made without first informing the account owner that it could materially increase GitHub Actions usage/cost, and without obtaining explicit approval for that cost-impacting change.

The repository workflow was also configured to run on both push and pull_request, so a single commit on a branch with an open PR could trigger two full CI runs. The agent later recognized that this duplicated expensive CI work and contributed to higher consumption.

The important issue is not whether GitHub Actions is technically appropriate. The issue is that an AI agent should not silently change an execution pattern in a way that can increase charges or exhaust quotas on a connected third-party service.

User impact

  • GitHub Actions consumption increased substantially during the project.
  • The monthly included Actions quota was exhausted.
  • The user attempted to add/adjust GitHub billing because the cause of the increased usage was not initially apparent.
  • The user had purchased a ChatGPT Plus subscription and did not expect an agent-driven workflow change to create materially higher usage on a separate paid service without notice.
  • The user only discovered afterward that the agent had intentionally shifted more full-regression work from local tools to GitHub Actions.

Expected behavior

Before an agent makes or recommends any change that may increase consumption of a metered external service, it should do one of the following:

  1. Ask for explicit user approval for the cost-impacting change; or
  2. Operate under a previously established user-approved rule/budget that clearly authorizes such usage.

This should apply to connected services such as CI/CD, cloud compute, hosted databases, paid APIs, storage, messaging, or any other resource where tool usage can create charges or consume limited paid quotas.

At minimum, the user should be told:

  • which external service will be used;
  • what execution pattern is changing;
  • whether the change can increase usage or billing;
  • whether repeated/duplicate executions are possible;
  • and what lower-cost alternative exists.

Requested safeguard

Please consider a product-level guardrail for agentic actions with external cost impact:

No new or materially expanded metered third-party usage without explicit account-owner consent, unless the user has already granted an appropriate standing authorization/budget.

A useful model would be similar to permission scopes:

  • no-cost/read-only operations: normal authorization;
  • ordinary writes: existing write permission;
  • actions with potential external monetary/quota impact: separate explicit consent or an approved spending/usage policy.

The agent should also surface duplicate-trigger risks such as push + pull_request CI before enabling or relying on them as a repeated validation strategy.

Why this matters

An agent can have technically valid write access to a repository while still lacking the user's economic authorization to increase consumption of a separately billed service. Repository permission and spending permission should not be treated as equivalent.

This report is specifically asking for a consent and cost-governance safeguard, not merely a CI optimization.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 15 hours ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #41134

Powered by Codex Action

aboozar-droid · 14 hours ago

Additional evidence: actual billed third-party cost occurred

I can now provide concrete billing evidence from the connected GitHub account for the same period.

For August 2026, GitHub Billing shows the following metered usage breakdown:

  • GitHub Actions gross usage: $18.04
  • GitHub Actions billed amount: $6.04
  • Copilot gross usage: $4.69
  • Copilot billed metered amount: $0

This confirms that the concern described in this issue was not merely theoretical: the execution-pattern change resulted in real externally billed usage, and the billed metered amount was attributable to GitHub Actions rather than Copilot metered usage.

The usage graph also shows a pronounced increase in Actions consumption in the later part of the month, especially around/after August 23, which is consistent with the period when the workflow became increasingly relied upon as a full-regression validation gate.

There is also a concrete duplication mechanism in the repository workflow: the CI workflow is configured to trigger on both push and pull_request. For a branch with an open PR, a single pushed commit can therefore produce two full CI runs. We verified this on one exact commit, where the same SHA triggered both a push run and a pull_request run.

The workflow itself is non-trivial and includes multiple hosted-runner jobs and services, including PostgreSQL, MinIO, Ruff, MyPy, Alembic migration checks, full pytest regression, Commerce integration acceptance, dependency audit, frontend install/build/test, and Playwright E2E. Repeating that workflow on both triggers materially increases metered runner consumption.

The governance concern therefore has three concrete parts:

  1. A connected-agent workflow strategy was materially expanded without explicit cost-impact consent.
  2. That strategy used a separately metered third-party service and generated real billable usage.
  3. The agent did not proactively identify or surface the duplicate push + pull_request trigger pattern before repeatedly relying on the workflow as an authoritative validation gate.

This reinforces the requested safeguard:

Technical write/access permission to a connected service should not be treated as economic authorization to materially increase metered usage. Agents should require explicit account-owner consent, or operate under a previously approved spend/usage policy, before expanding usage patterns that can create third-party charges or exhaust paid quotas.