GitHub App接账单：别再用个人PAT跑自动化
企业账单自动化里，一个很常见的实现是：
财务脚本
↓
某个Enterprise Owner的PAT
↓
GitHub Billing API
这套方案真正的问题不是 Token 会不会过期。
而是它把：
企业自动化身份
绑在了：
某一个人
身上。
GitHub 8月26日新增 Enterprise Billing GitHub App 权限后，这个历史问题终于有了更合适的解法：GitHub App 现在可以获得企业账单权限，并明确分成：
Read
Read & Write
安装级 Access Token 可以访问 Enterprise Billing REST API，用来拉使用量、对账、管理预算和 Cost Center；同时不再依赖 Enterprise Owner / Billing Manager 的个人 PAT，而且 GitHub 表示 App Token 还拥有比 PAT 更高的 Rate Limit。
这件事最值得企业自动化借鉴的是：
机器工作流应该使用机器身份，而不是借一个人的身份长期运行。
个人PAT为什么迟早出问题
假设：
billing-sync
由张三创建。
PAT 属于：
zhangsan
半年后：
张三离职
你会遇到：
Token被撤销
↓
月末对账突然失败
或者更糟：
为了避免失败
大家不敢撤掉旧Token
最后形成“幽灵身份”。
GitHub App的边界更清楚
身份：
billing-automation-app
不是：
employee-zhangsan
权限：
enterprise_billing: read
或者：
enterprise_billing: write
安装：
目标Enterprise
Token：
Installation Access Token
天然更适合长期自动化。
第一原则：默认只给Read
大多数财务采集任务只需要：
Usage
Invoice Reconciliation
BI Dashboard
这些都应该只给：
Read
不要因为未来“可能要改预算”，一开始就给：
Read & Write
权限最大化。
我会拆成两个App
billing-reader
enterprise_billing:
READ
用途：
同步Usage
对账
BI
异常检测
billing-controller
enterprise_billing:
READ_WRITE
用途：
修改Budget
修改Cost Center
两个独立 App。
不要把“读数据”和“改财务控制”放在同一个 Credential 里。
为什么拆App比运行时判断更稳
如果同一个 Token 拥有 Write：
代码Bug
错误参数
被污染的Agent决策
都有机会触达写接口。
如果 Reader Credential 根本没有写权限：
再聪明的Agent
也无法写
这就是硬边界。
Access Token不要长期落盘
正确流程：
App Private Key
↓
短期JWT
↓
换Installation Token
↓
调用Billing API
↓
Token自然过期
应用数据库不要保存：
长期Installation Token
更不要复制到：
.env
CI日志
Agent Prompt
自动化最好把Credential Broker独立出来
Agent 或业务服务只请求：
github.billing.read
Broker 再负责：
选择GitHub App
签发Token
调用API
public interface CredentialBroker {
AccessCredential issue(
String capability,
String enterpriseId);
}
业务代码不接触 App Private Key。
财务写操作必须二次控制
比如：
修改企业Budget
不能因为 App 有 Write Permission 就自动执行。
真正链路应该：
Agent/Rule提出变更
↓
生成Proposal
↓
Policy检查
↓
Approval
↓
billing-controller执行
一个Budget Change Proposal
public record BudgetChangeProposal(
String enterpriseId,
String costCenterId,
BigDecimal currentBudget,
BigDecimal proposedBudget,
String reason,
String sourceDataSnapshot,
String actionHash) {
}
批准绑定：
actionHash
审批后参数变化：
重新审批
写权限还要限定变化幅度
例如：
billing_policy:
max_auto_increase:
percent: 5
approval_required:
above_percent: 5
forbidden:
- delete_cost_center
即使 Controller App 有 API 权限，业务 Policy 仍可以继续收紧。
Usage同步要做Snapshot
不要每天只覆盖：
current_usage
更好：
usage_snapshot
create table github_billing_snapshot (
enterprise_id varchar(128) not null,
captured_at timestamptz not null,
source_hash varchar(64) not null,
payload_ref varchar(512) not null,
primary key(
enterprise_id,
captured_at
)
);
这样月底可以回放：
某天为什么报警
Billing数据也需要Source Hash
如果 ETL Bug 修改了数字，后面很难追。
Snapshot 保存：
Raw Payload Hash
Normalized Data Hash
对账时知道：
源头变了
还是转换逻辑变了
Rate Limit更高不代表可以无限拉
GitHub 明确说 App Installation Token 相比个人 PAT 有更高 Rate Limit。
但同步仍然应该：
增量
缓存
分区
不要因为限额更高就：
每分钟全量扫Enterprise
一个合理同步节奏
Usage Dashboard:
15min
Budget Alert:
5min
Month-end Reconciliation:
daily full snapshot
不同用途不同频率。
App权限变更必须审计
如果：
billing-reader
READ
某天被改成：
READ_WRITE
这本身就是重大安全事件。
应该触发：
Permission Drift Alert
我会保存App Permission Snapshot
{
"app": "billing-reader",
"enterprise_billing": "read",
"captured_at": "...",
"config_hash": "..."
}
每天或每次部署检查。
发生 Diff：
- read
+ write
立即通知 Owner。
App Owner不能是一个人
GitHub App 是机器身份，但治理责任仍然要有人。
最好绑定：
Owning Team
On-call
Security Reviewer
Business Owner
而不是：
created_by=zhangsan
作为唯一归属。
一个机器身份清单
app: billing-reader
owner_team: finops-platform
capabilities:
- github.enterprise.billing.read
private_key:
location: secret-manager
rotation:
days: 90
write_access: false
这比把 App 配置留在 GitHub UI 里没人管更稳。
不要让Agent直接拿Billing App Token
如果未来做 FinOps Agent：
分析Copilot成本
→建议预算
Agent 只需要看到抽象 Tool：
get_usage()
get_budget()
propose_budget_change()
不要给它：
raw REST token
Tool Gateway 才是权限边界。
最少测这8件事
1. Reader不能调用写接口
2. Controller写操作需要审批
3. 员工离职不影响App
4. App Token过期后能自动刷新
5. Private Key不会进入日志
6. 权限从Read变Write触发告警
7. Usage Snapshot可回放
8. Budget变更Action Hash变化会重新审批
GitHub App 新增企业账单权限，看起来只是一个 API 权限变化。
真正重要的是它让账单自动化可以从：
借用Enterprise Owner的个人身份
迁到：
独立机器身份
这种迁移不只适合 GitHub。
凡是长期运行的：
财务同步
安全扫描
部署机器人
报表Agent
都应该问同一个问题：
这个工作流为什么还绑定在某个人的长期 Token 上？
能改成 App / Workload Identity 的地方，越早改越好。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/