Your inventory says the agent exists. It does not say how far it reaches.
Describe one agent in five questions. Watch the reach travel: the identity it signs in as, the connectors it can call, the data that puts in scope, and the actions it can take that nobody can undo. Then see which of those things another agent reaches too.
Free, no signup, and no connection to your tenant. Nothing you type leaves your browser.
Name one agent that is live in your tenant right now.
The one you would not want to explain in an incident review. Answer five questions about it and watch how far it reaches. Nothing connects to your tenant and nothing you type leaves this browser.
What does it sign in as?
The identity is the reason the rest of the reach exists. An agent cannot reach past what the account it runs as can reach.
Inventories answer the wrong question.
Every admin surface will tell you which agents exist, who made them and when they last ran. None of them tells you what happens when one misbehaves, because reach is a property of the graph, not of the agent. The identity is the reason the rest of the reach exists, and it is almost never the thing on the inventory screen.
Granted scope, not exercised scope.
An agent that has only ever read a document library still holds every permission in its manifest. The reach you have is the reach you granted, available the moment something goes wrong or somebody changes a prompt. That is why this asks what is in the manifest rather than what it does on a normal Tuesday.
The five layers reach travels through
Bottom to top, in the order reach moves. A connector can put an action in scope without touching data on the way, which is why the planes are a reading order rather than a claim that reach stops at every floor.
- 01
Identity
who the agent runs as
- 02
Agents
the agent itself
- 03
Connectors and tools
what it can call
- 04
Data
what it can read
- 05
Actions
what it can change
The five questions, and why each one is asked
Take these to whoever built the agent. The answers are the inputs to everything the tool draws, and four of the eight controls fall straight out of them.
What does it sign in as?
The identity is the reason the rest of the reach exists. An agent cannot reach past what the account it runs as can reach.
What can it get to?
Pick what is in the manifest, not what you think it uses. Granted scope is what defines reach, not exercised scope.
Can it change anything?
Reading is recoverable. Writing is the half that needs a person, and sending is the half that cannot be taken back.
What sets it off?
This is the question that decides whether anybody is there when it goes wrong.
Who is answerable for it?
A named person who can authorise switching it off. A distribution list cannot be paged at 2am and cannot sign anything.
The eight controls
Six of these can be scored from five answers. Two cannot, and the tool leaves them unknown on every run rather than flattering the result. Unknown is usually where this breaks.
Named owner
A person, not a team alias, answerable for this agent.
Scoped identity
Runs as an identity scoped to the job, not a standing tenant-wide principal.
Least connector
Every connector in the manifest is one the agent demonstrably needs.
Data boundary
The data in reach is bounded by something other than the identity default.
Halts when unattended
An irreversible action halts for a person even on a scheduled trigger or an API call.
Logged and attributable
Each action traces to one accountable human, not a shared mailbox.
Reviewed since change
The manifest was reviewed after the last change to its permissions.
Decommission path
A named route to switch it off, with the owner who can authorise it.
What this tool is not
- Not a scan. It never connects to a tenant, reads a manifest or calls an API. It draws the picture your five answers describe, in your browser.
- Not an inventory. Microsoft already tells you which agents exist. This is for the question that comes after.
- Not a verdict on your estate. One agent, five answers. The other agents in the picture are a fictional sample tenant and are labelled as such, so the shared-surface finding shows you the shape of the problem rather than a claim about your organisation.
Securing Agents in M365 Copilot
This tool runs one agent from memory. The kit runs the estate: the eight controls as a verification procedure, read-only scripts that collect the evidence, the register, and the gate that decides whether an agent ships, gets narrowed, or gets switched off.
See the kitNot ready for the kit? The Agent Security Verification Checklist (Lite) is free: seven printable checks and one read-only script, enough to size one agent in an afternoon.
One useful thing every other Tuesday
AI at Work: what actually changed, what it costs, and what to do about it. Checked against the vendor’s own pages before it ships.
Where to next
Securing Agents in M365 Copilot
The eight controls as a verification procedure, with the read-only scripts, the register and the ship-or-stop gate.
Go→The Triage Floor
Before you secure the agent, check the process should exist. Ten evidence questions and six gates, free.
Go→More free tools
The Copilot cost calculator, the allocation method checklist, and the rounding checks where the decimals decide.
Go→Kesslernity. Independent practitioner, no vendor sponsorship. This tool makes no connection to any tenant and sends nothing anywhere: every number on screen is computed in your browser from the five answers you gave. The surrounding estate is invented and labelled as invented. Output is a planning aid, not a security assessment, and not legal or audit advice.