The scenario
An operations lead connects a meeting-scheduling agent to their work account so it can read calendars, propose times and send invitations. The consent screen mentions calendar access, but the integration the agent uses requests the vendor's default scope bundle: mail read and send, file read and write, directory read and chat. The lead clicks accept, because the agent works and the dialog was long.
The lead is also an administrator of the document repository and a delegate on the executive team's mailbox. The agent now holds a token that can read board minutes, send mail as the lead and download any file the lead can open. It uses none of that for scheduling, but a prompt injected through a calendar invitation from outside the company, a meeting description written as an instruction, only needs to point the agent at capabilities it already has. When the agent is recommended to the rest of the team, each new connection inherits a different person's authority, and nobody can say what the agent, collectively, can do.
Why it happens
- OAuth grants are per app, and apps ask for more than they need. Scope bundles are designed for the vendor's convenience; the user sees a consent dialog, not an authority model.
- Agent authority is a copy of human authority. Delegated tokens carry every permission the human holds, including the ones that have nothing to do with the agent's job.
- Purpose is nowhere in the grant. Nothing records that this token exists to schedule meetings, so nothing can flag mail-send or file-download as out of purpose.
- Scale hides the aggregate. Ten users connecting the same agent create ten different authority sets under one agent name, and no single view shows the union.
How Trustivan helps
Inventory agent connections as identities. Finding an agent through the OAuth grants it holds is agent discovery, which Trustivan does not do by design; no connector reads SaaS OAuth grants either.
Not builtCompare granted scopes with the agent's job. No connector reads SaaS scopes yet. For an agent in the inventory, the tools an operator entitled it to are the recorded statement of its job, and the gate decides against them.
Future capabilityShow aggregate authority across users. The union of inherited scopes across every connection needs SaaS connectors, which do not exist yet. Effective access of an agent identity on the graph is available as an upper bound.
Future capabilityRecommend a scoped grant. Proposing a minimal scope set needs the scopes, which nothing reads yet. A remediation can still be proposed and approved by a second person; nothing executes at the vendor.
Future capabilityTrack the reduction as lifecycle. An owner, a declared autonomy and any approved policy exception are recorded against an agent identity in the inventory, the same way they are for any other identity.
Available
What the evidence looks like
For an overprivileged agent the evidence has to compare what was granted with what the agent's job requires and what it has actually called. Illustrating the problem:
| Question | Illustrative answer |
|---|---|
| Why | Scheduling agent holds mail, file and directory scopes it never uses, inherited from an administrator |
| What | meeting-planner agent · 14 OAuth connections · delegated refresh tokens |
| Who | Authorised by ops lead m.okafor (repository admin, executive mailbox delegate) and 13 colleagues |
| Where | Workspace tenant corp-main · third-party app registration |
| How | Default scope bundle accepted on consent: calendar, mail read/write, files read/write, directory read, chat |
| Blast radius | Executive mailbox, about 9,400 documents, send-as for 14 users, directory export |
| Recommendation | Re-consent with calendar read/write only; move to a dedicated agent identity; revoke the 14 existing tokens |
| Action | Scope diff sent to each authorising user · re-consent campaign staged · out-of-purpose scopes listed per connection |
| Evidence | OAuth grant records · agent tool-call log (no mail or file calls in 90 days) · directory role membership · consent timestamps |
Related capabilities
- Agent Permissions — the tools an operator entitled to an agent, and its effective access
- Agent Identity — dedicated agent identities instead of borrowed human delegation
- Agent Tools — each tool's effect, as its publisher or an operator declares it
- SaaS environments — OAuth apps and consent, which no connector reads yet
- Blast Radius — mailboxes, files and directories reachable through the inherited token