"What is this agent allowed to do?" Everyone asks it — security reviews, auditors, the board after a headline. Almost nobody can answer it from evidence. Config files say what was granted; they say nothing about what actually happens. Wytness answers the question from the other side: the permissions your agents actually exercised, action by recorded action.
Exercised, not granted
Every recorded tool call carries the permission scopes the agent's runtime declared when it acted. Collect those across the stream and you get something subtly different from an IAM report: not the theoretical ceiling of what an agent might do, but the observed floor of what it demonstrably did. We're explicit about this boundary — the view is a lower bound. Wytness does not infer granted scopes from your OAuth or IAM configuration; an agent may hold permissions it has never used, and those won't appear here. That honesty is what makes the number useful.
Because the gap between the two views is the interesting part. Granted-but-never-exercised is your least-privilege to-do list — capability sitting idle, all risk and no payoff. Exercised in ways nobody remembers granting is the finding that makes a review worth running. Neither gap is visible from either side alone: IAM can't see usage, and logs without scopes can't see authority. Holding both views is the trick, and the recorded side is the one that was missing.
Three ways into the same question
- From an agent: its Permissions tab lists every scope that agent has exercised — the observed shape of what it does, ready to compare against what it was supposed to do.
- From a tool: the scopes flowing through that tool, across all the agents that call it.
- From a permission: the reverse lookup. Pick one scope and see every agent, every tool, and the recent events that exercised it — in effect, the observed blast radius of that permission.
A revocation, walked through
Here's the reverse lookup earning its keep. Security wants to revoke a broad scope an old integration once needed. The pre-recorder version of this change is archaeology: grep configs, ask around, revoke, and wait to see what breaks. The recorded version: open the permission's page, see that exactly two agents exercised it in the last thirty days — one on a tool that's being retired anyway, one that genuinely needs a narrower scope. Now the change ships with a worklist instead of a prayer, and the after-check is the same page a week later: exercised by nobody, safe to close out. Evidence turns "revoke and hope" into "revoke and verify."
What teams do with it
Beyond revocations: roll out a new scope, come back a few days later, and check that the callers match the plan — surprises are least-privilege flags caught in week one instead of audit week. And because each tool carries its risk tier, a permission that flows mostly through high-risk tools announces itself as the place to tighten policy first. The page effectively ranks your governance backlog by observed behaviour — which beats ranking it by whoever asked loudest.
Why evidence beats intention here
Permissions are where agent governance gets real: they're the difference between an agent that could theoretically do damage and one that has the demonstrated habit of touching sensitive capability. A recorded, verifiable history of exercised scopes turns "we believe the agent is scoped correctly" into "here is what it has actually done, and here is the proof." One of those sentences survives an audit.
It also changes the tone of the audit itself. When the auditor asks the access-management questions — who can do what, how is it reviewed, how do you know — the answer is a page you open, not a controls narrative you wrote the week before. Reviews built on observed permissions take hours, stay current by themselves, and leave a signed trail of the very evidence they relied on.
Permissions pair naturally with Tools — what agents touch, and what they were allowed to touch it with. Questions about how scopes show up in your events? Ask us.