A branch came in for review with about sixty commits on it, every one authored by someone on the team. He hadn't written them. Claude Desktop had, running on his laptop, signing commits with the git identity we configured during setup. As far as the repository was concerned, the work was his. As far as blame, audit and every code-ownership convention we had, the work was his. Nobody could separate the four or five decisions he had actually looked at and accepted from the fifty-odd changes the model produced while he clicked through the result to see whether it worked.
We moved the whole thing off his machine: the model runs server-side now, the working copy is provisioned per ticket in an isolated environment, and what comes back is a URL. That solved the port conflicts and the dependency drift, which was why we did it. It did not solve the attribution problem. It relocated it. Now a service account commits, and the service account is one identity shared by every run, for every person, on every ticket.
That is the shape of the thing arriving at enterprises considerably faster than most access-management programmes are ready for.
a new hire, a printer, and an agent
Take a new hire in their first week. They have a unique identifier that will never belong to anyone else, a set of permissions somebody requested by name, a login trail, and an offboarding procedure that takes an afternoon. Four things: who they are, what they can reach, what they did, and how you get rid of them. Hiring, permissions, audit, firing.
Now the printer on the third floor. It has an asset tag, it sits on a network segment that lets it reach the print server and nothing else, it logs every job, and you can unplug it. Same four things. Nobody is impressed by the printer, but the printer is fully accounted for.
Now the agent your team stood up last month to triage tickets, read the CRM and post summaries into Slack. Who it is: it uses a key minted from a human account, probably belonging to whoever built the thing. Every log in every downstream system records that person, not the agent. What it can reach: whatever they could, which for an engineer with admin rights is usually everything. What it did: indistinguishable from what the human did. How you fire it: you rotate the key, and you find out what else breaks.
Nobody decided the agent could write to the CRM. It inherited the permission from the account it borrowed.
where the answers get uncomfortable
Identity means a credential belonging to this agent and only this agent, distinguishable in every downstream system's logs from the human who deployed it and from the other eleven agents your company is running. A name in a config file does not qualify. Whether you can have this depends entirely on the platform. API-native services handle it well: Anthropic, OpenAI, Stripe and others will issue a key with its own permissions and its own name, no seat required. The business systems where most agents actually work are the problem. Salesforce, HubSpot and most CRMs model access around seats occupied by people, so a separate identity per agent means paying for a seat or sharing a credential, and sharing is what teams choose.
Scope is what it can touch, expressed as operations rather than systems. "Read from the ticket store, write to one Slack channel, call the pricing endpoint" is a scope. "Has an API key for Salesforce" tells you nothing about what the thing can actually do. The trade-off is real and worth stating plainly: narrow scopes break more often, and every break lands on the person who understands the permission model, which is never the person operating the agent. Broad scopes are cheaper to run and quieter, right up until the day they aren't.
Attribution needs three facts on every action rather than one: which agent did it, which run it belonged to, and which human or system event authorised that run. What we ended up doing was giving every run its own number, and making sure that number appeared everywhere the run left a mark: in the commit, in each API call, in the ticket it came from. So anything the agent touched could be traced back to one specific run and to whoever started it. It is unglamorous plumbing, and it is the difference between a twenty-minute investigation and a week of reading diffs, which is the recurring governance cost that shows up after the agent is already built.
Revocation is where the situation exposes itself, because revocation and identity turn out to be the same problem seen from opposite ends. Try it. Pick an agent running in production and cut off its access without touching anything else. If the credential is shared you cannot, so you rotate the key instead, and the rotation takes down the nightly export, two internal dashboards and something somebody wired up in March, because they all use the same key and nobody wrote down that they did. The rotation gets scheduled, then deferred, and the agent you wanted to stop keeps running for another eleven days.
That delay is the test. If cutting off one agent requires a change-management window, what you have is not a revocation path. It is an intention to revoke, subject to scheduling.
the parts exist, the whole does not
Every piece of this problem has been solved somewhere, and none of the solutions cover the ground you need. Cloud providers can issue an identity to a running process and rotate it automatically, which works cleanly as long as everything stays inside one cloud. Credentials that expire in hours rather than years are normal practice in infrastructure and almost unknown in the business tools where agents actually operate. And there is no single place to go and switch one agent off across Salesforce, your warehouse and a third-party API, because each of them keeps its own list. You will build this out of parts, and it will not be elegant.
What you can do now costs engineering time once rather than exposure forever. Mint a distinct credential per agent per purpose, even when the platform makes you buy a seat to do it, because the licence fee is cheaper than the incident. Keep a register of which agent holds which credential, with an owner's name on each row, because the thing that makes revocation slow is not the API call, it is not knowing what breaks. Give every credential an expiry date when you create it, so that the ones nobody remembers stop working on their own rather than living forever. And stop letting agents inherit a human's permission set as a starting point, because a permission set assembled over four years of a career is the worst possible baseline for a process that only needs to read tickets. This is the same logging, testing and oversight floor most companies never built, arriving now with agents attached.
verifiable agent identity is coming, and retrofitting is expensive
In June 2026 Estonia approved a framework giving AI agents a verifiable digital identity, with permissions that are scoped, auditable and revocable, tied to the eIDAS 2.0 ecosystem. It is an approved framework rather than a law in force, and that distinction matters. What requires no guessing is the direction: the first government to treat agent identity as identity infrastructure rather than a vendor feature has now done so.
Plan around it. At some point an agent acting on a company's behalf will be expected to have a verifiable identity, and someone will have to be able to say which one acted and on whose authority. Retrofitting attribution onto a fleet of agents that all share one service account is going to be a genuinely expensive project.
One thing worth doing, and it takes an hour. Take an agent already running in production and try to switch off its access alone, in a staging environment that mirrors how your credentials are set up. Time it, and write down what else stopped working.
That is your answer to how you would fire that agent. Ask the same question in a meeting and you will get "we'd rotate the key," which is a description of an action rather than an outcome. The hour tells you what the action actually costs. That is the number worth knowing before you need it.
faq
Why can't we just give each AI agent its own account in every system?
Sometimes you can, and where you can you should. API-native platforms will issue a key with its own permissions and no seat attached. The obstacle appears in business systems priced per user, which have no concept of a non-human account, so a separate identity for each agent means buying a seat. Buy the seat. It costs less than the incident.
What does agent attribution actually require in the logs?
Three facts on every action: which agent performed it, which run it belonged to, and which human or system event started that run. The minimum that makes an investigation possible is giving each run its own number and carrying it through every call the agent makes.
Isn't narrow scoping more trouble than it's worth?
Narrow scopes break more often, and every break lands on the person who understands the permission model rather than the person operating the agent. Broad scopes are cheaper and quieter until the day they aren't. The trade-off is real; it is a decision to make deliberately rather than by default.
How do we know if our revocation path works?
Test it. Pick an agent running in production, switch off its access alone in a staging environment that mirrors your credential setup, and count what else stopped working. If doing it for real would need a change-management window, you don't have a revocation path yet.
