A team spends two weeks deciding what its new agent may do. Read the ticket queue, write to a branch, never touch production. It is careful work, and it answers the wrong question.
The agent is not getting a permission set. It is going into an application that already has one. Whatever that application's service account, API keys, and OAuth grants can reach, the agent can reach, because it runs as that application. The scoping document describes intent. The identity describes capability. So inventory the application's credentials, and revoke what nobody can justify, before you scope the agent.
We have built and maintained ColdFusion systems since 1998, and most of the applications we inherit are a decade old, written by people who have since moved on. On a system that old, the distance between intent and capability is wide.
Vendor controls cover the vendor's agent sessions
Vendor agent controls govern the sessions the vendor runs, not an agent you embed in your own application. They are real, and they are getting better. On September 9, 2026, GitHub gave Copilot Business and Enterprise administrators managed permissions for agent operations. Shell commands, file reads and edits, and network domains can each be blocked, held for human approval, or allowed. User and workspace settings cannot weaken those rules. If your developers use Copilot's agent, turn this on.
Then look at what it covers. It governs the agent sessions GitHub runs: the Copilot app, the Copilot CLI, and Visual Studio Code sessions on its agent host. It says nothing about the token your billing service has held since 2017. An agent you embed in that service calls out through the service's own code, under the service's own identity. None of those checks sit on that path.
What permissions does an agent inherit from an old application?
An agent inherits every credential the application holds, and on a ten-year-old system that list is long. Pull the credentials on an inherited system and it usually looks like this:
- A service account created for one integration that now serves six. Each new integration widened its scope. Nobody ever narrowed it.
- OAuth grants to vendors nobody uses anymore. The contract ended. The consent was never revoked.
- Datasource passwords in the ColdFusion Administrator or a config file. They work, so nobody has read them since the last migration.
- A shared administrator credential from the original build. It is in a runbook, in someone's password manager, and probably in a chat message from 2019.
None of this is exotic. It is the ordinary sediment of a system that has run long enough to be worth automating.
The gap is ownership, not tooling
On an old application, the missing piece is an owner for each credential, not a better tool. A non-human identity is a credential software uses instead of a person: a service account, an API key, an OAuth token. The Cloud Security Alliance's May 2026 whitepaper on non-human identity governance cites survey data showing that only 20% of organizations have formal processes for offboarding and revoking API keys. It also cites research finding that 47% of non-human identities had gone unchanged for more than a year. Its fixes are sound: a central registry, an owner and a purpose for every credential, and lifecycle reviews. Most of them assume an identity program already exists.
The mid-market version is smaller and harder. There is no identity program. There is a list of things that currently work and a reasonable fear of touching any of them, because the person who knew what would break left in 2021.
Do the inventory before the scoping
Inventory the application's credentials before anyone scopes the agent. We do it in four steps:
- List every credential the application holds. Check config files, environment variables, the secrets store, and the source code. The dangerous ones never made it into a store.
- Ask each credential what it can reach. Ignore what it was issued for. Call the provider's API and read the actual scope back.
- Name an owner, or record that there is none. An unowned credential in an agent's path is a decision nobody will make later.
- Revoke what the inventory cannot justify. Do it now, while a breakage still traces to a change you made on purpose.
The last step takes most of the week, and it is the one teams skip. Revoking a credential you cannot fully explain is uncomfortable. It is much cheaper now than after an agent has used that credential a hundred times a day. Our pre-production credentials audit covers the secrets you hand an agent on purpose. This inventory covers the grants it gets without asking, and runtime containment for agents without a platform team limits what it can do with whatever survives.
The order matters more than the rigor
A carefully scoped agent on an unaudited identity is a governance document, not a control. An ordinary agent on a credential set somebody has actually read is a system you can reason about.
The inventory is unglamorous. It is usually the first week of work when we put an agent inside an existing application, because the scoping conversation means nothing until someone knows what the application can already reach.