Once a tool acts for a person, there are two identities in every request and your system probably records one of them. The person, because that is whose permissions were checked, and the tool, which usually appears nowhere at all.
Fixing that is not a new authorisation model. It is a narrower credential and an extra claim, both of which already exist in the specifications, applied consistently enough that a reviewer can see the difference.
Exchange down, never reuse across
The pattern is a token exchange: present the user's credential, ask for one that is narrower, and receive a token restricted to a subset of scopes with a short lifetime and an audience naming the specific service it may be presented to. The tool never holds the original, so a compromise of the tool does not yield the person's full authority.
The audience restriction is the part most often skipped and it matters as much as the scope. A token that any of your services will accept can be replayed by whichever one receives it against all the others. Naming the intended recipient turns a leaked token into a credential for one narrow surface.
- Scopes chosen per task, not per integration, and always a subset
- Audience naming the service that may accept it
- Lifetime measured in the length of a task, not the length of a deployment
- No path that exchanges a narrow token back into a broader one
A token every one of your services accepts can be replayed by whichever one receives it against all the rest.
Record both parties on every event
Delegated tokens carry an actor claim describing who is acting for the subject. Read it, propagate it, and write both into every audit event, so the record says this action was taken by this tool on behalf of this person. The alternative is an audit trail that attributes automated actions to a human who was asleep, which is worse than no record because it is confidently wrong.
Carry the chain when there is one. If a tool invokes another tool, the trail should not flatten into whoever called last. A reviewer asking what touched this account deserves the whole path, not its final hop.
The interface is the missing half
All of the above can be true and still invisible. What a person can see is what they can control, so build the page: everything currently holding a delegated grant on this account, what each may do stated in plain words, when it last acted, and a revoke button that takes effect on the next request rather than at expiry.
Grant the same view to organisation administrators for their members, because in an enterprise the person accountable for access is rarely the person who clicked approve. The products that handle this well will be the ones where a security reviewer can examine tool access the way they examine employee access: a list, a scope, an expiry and a log.
- A visible inventory of grants, per user and per organisation
- Scopes described in words a non-engineer can evaluate
- Revocation effective immediately, not at the next expiry
- Notify on first use of a new grant, the way a new device sign-in is notified
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.