How to Budget a Coding-Agent Permission Inventory

A coding-agent permission inventory is not just a security spreadsheet. It is a cost map of every repository, secret, cloud action, tool, and data source an automated workflow can touch. Without that map, teams pay twice: once for access nobody can explain and again when legitimate work stalls behind emergency reviews.

The inventory should answer five questions for every grant: which identity holds it, what tasks require it, which resources it reaches, who owns the decision, and when the justification expires. Build from machine-readable sources such as repository roles, OAuth grants, cloud IAM, CI tokens, MCP configuration, and gateway policy. Interviews fill gaps but should not be the system of record.

Define the Inventory Boundary

Include interactive assistants, unattended agents, service accounts, sandbox credentials, deployment integrations, webhooks, plugin marketplaces, and fallback models that can invoke tools. Track inherited access and group membership. An agent may appear read-only in one console while its service account inherits a write role elsewhere.

Separate discovery from interpretation. First collect evidence exactly as systems report it. Then map provider-specific roles to normalized capabilities such as read code, write branch, merge, deploy preview, deploy production, read logs, manage secrets, or change billing. Preserve the original role name so an auditor can reproduce the mapping.

Estimate First-Pass Labor

Count systems, identities, grants, and owners before estimating. A small team with six systems and 40 grants may need 20 hours of engineering and eight hours of owner review. At blended loaded rates of $100 and $120 per hour, the first pass costs $2,960. Add tooling, export limits, API development, and legal or privacy review when sensitive data is involved.

Price ambiguous grants separately. A well-named read role can take minutes to confirm; an inherited custom policy may require logs, test accounts, and vendor support. Use low, expected, and high scenarios based on the share of custom access. One average minutes-per-grant figure usually understates the tail.

Tie Permissions to Observed Tasks

Join grants with 30 to 90 days of tool and audit events. Mark a permission as used only when a legitimate completed task required it, not merely when a token containing the permission was presented. Distinguish attempted, denied, successful, and side-effecting operations. This creates evidence for removal without assuming unused logs prove zero need.

For rare incident capabilities, require an explicit break-glass justification rather than permanent routine access. Price the activation delay and drill it. A theoretically secure emergency path that nobody can execute under pressure creates its own outage cost.

Calculate Expected Exposure

• Estimate the probability of misuse, compromise, or agent error for each capability.
• Estimate investigation, recovery, downtime, notification, and customer impact.
• Account for blast radius, reversibility, environment, and data sensitivity.
• Publish ranges and assumptions instead of fabricating precise avoided loss.

Prioritize grants with both high consequence and weak task evidence. Removing fifty harmless reads may look productive while leaving one unnecessary production write unchanged. Weight the backlog by expected exposure and operational effort.

Remove Access Safely

Canary removals on low-consequence identities, monitor denials, and provide a time-limited recovery path. Record tasks that fail after removal, including token spend and engineer delay. Restore only the narrow capability that evidence supports. Do not respond to one confusing error by reinstating an entire administrator role.

Version the inventory and sign changes. Keep owner, evidence window, last used date, expiry, and removal result. Schedule reviews around organization changes, tool releases, repository archival, and new agent triggers. An annual snapshot decays too quickly for unattended automation.

Measure the Program

Use inventory cost per active agent identity, percentage of grants with owners and expiry, high-consequence grants without observed use, legitimate denial rate, and time to resolve access failures. Pair these with cost per safely completed task. A smaller permission count is useful only if work remains reliable.

The inventory becomes cheaper after the first pass when collection is automated and review focuses on deltas. Preserve immutable raw exports, normalized mappings, and approval history. That turns a periodic scramble into maintainable operating data.

Plan the First 90 Days

In days one through 30, collect raw grants and establish owners without removing access. In days 31 through 60, normalize capabilities, join observed tasks, and rank high-consequence ambiguity. In days 61 through 90, canary removals, test break-glass paths, and automate delta collection. This sequence creates evidence before disruption.

Reserve review capacity from repository, platform, security, and application owners. Publish unresolved grants rather than assigning false confidence. At day 90, report total grants, owner coverage, expiry coverage, removals, restored permissions, legitimate denials, review hours, and expected exposure ranges. The next budget should focus on the systems whose evidence remains most expensive to collect.

Bottom Line

Budget permission inventory as recurring infrastructure: discover, normalize, map to tasks, rank exposure, remove carefully, and review deltas. The return comes from fewer unexplained privileges and faster legitimate decisions. A complete list is only the beginning; task evidence and accountable expiry make it economically useful.