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:

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.

No source file, test, or implementation entry point is identified in the issue. Start by tracing how the agent handles connected GitHub Actions workflows and external-service authorization, including push plus pull_request triggers. Done should include an explicit consent or approved-budget safeguard for materially increased metered usage and visibility into duplicate execution risks.