Agent should require explicit consent before changing workflows that can increase external metered costs
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:
- Ask for explicit user approval for the cost-impacting change; or
- 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.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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:
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
pushandpull_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 apushrun and apull_requestrun.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:
push+pull_requesttrigger pattern before repeatedly relying on the workflow as an authoritative validation gate.This reinforces the requested safeguard: