An agent’s reach is decided, not assumed.
Whatever a person, an agent or an app asks to do passes one decision point before anything runs. An agent can never do more than the person it acts for, a call that does not say how far it reaches is refused, and where a decision needs a person the work waits for them. Every answer is recorded with its reason. Control isn't a setting you bolt on. It's the path the call takes.
An agent asks
Export the full customer list
- resolved: Identityacting for Lea, Sales
- passed: Capabilityarmed with it
- refused: Reachnot stated by the call
- passed: Auditrefusal recorded, with its code
One decision point.
Four plain pieces.
One service answers "may this subject do this?", and it answers the same way for a person, an agent, or a background service. It evaluates a relationship graph rather than a flat list, so team nesting and role assignment are resolved at the moment of the check — not baked into a copy that can go stale.
One named action.
The unit of control, spelled out: domain, resource, verb, version. Nothing an agent can do is unnamed, and nothing is implicit.
Who holds which capability.
A capability held by a subject — a person, a team, an agent, a service. This is what the decision point checks.
A reusable bundle.
Group capabilities into a role once and assign it wherever you need it, instead of granting them one at a time.
A group, with nesting.
A team can contain sub-teams. Assign a role to the parent and the membership is expanded transitively when the check runs.
Your files, your mail.
Only what you can see.
Agents reach the places your people already work. Connectors read Google Drive, SharePoint, Teams and Slack, and search across the enterprise, using the user’s own access. An agent never sees a file its user could not open.
1Connectors with the user’s access
Ask about a contract and the agent searches the folders you may open. A colleague asking the same question may get a different answer.
2Acting in Microsoft 365 or Google
An agent can draft the mail, book the meeting or update the sheet as the person it works for. The action is theirs, so the limits are theirs.
3Posting is a capability too
Writing to a Teams or Slack channel needs a grant, and a high-risk post can need an approval. Without one, the call is refused and says why.
An agent can never
exceed its owner.
What an agent can actually do is the intersection of three things, and each one is a separate refusal on the way in: a capability it was never armed with is not offered and not invocable; the reach ceiling is applied to the decision; and the decision itself is clamped to the authority of the person the agent acts for. A low-privilege person's agents are low-privilege by construction — there is no setting that raises them.
One choice decides
how far an agent reaches.
No jargon, no checklists. Pick a tier — each a superset of the last. The default, As me, is the one you rarely change: the agent acts with exactly your authority, so an agent that declares no tier at all is already the safe one. A capability that reaches further says so itself, in its own declaration — so no central list has to be kept up to date, and nothing can be forgotten off it.
Silence is a refusal,
not a default.
Every capability invocation goes through one router, and it passes the same stations in the same order. Each station can only ever narrow. The stations that can fail do fail closed — an unresolvable answer is a refusal, never a pass-through.
1It must say how far it is reaching
An agent invocation that states no aperture is refused, and so is one whose aperture cannot be resolved. An unstated intention is not read as a modest one.
2It may not widen its own authority
A separate guard sits in front of the policy decision for calls that would change who may do what — so a capability cannot be used to grant itself more.
3Then the decision, in an organisation
Allow, deny, or needs approval. A call that names no organisation is refused before any policy is consulted, so a decision is never made outside a tenant.
4Then the ceilings, in order
The agent's reach tier is applied to the decision, then the environment's own ceiling on top. Neither can widen what the owner's authority already allowed.
A tool is a capability.
It says what it can do.
A skill, an MCP tool or a built-in action is registered as a capability before an agent can call it. Each one carries a risk tier and an effect class: read, write or admin. Those two facts decide who may hold it and who has to approve its use.
1Read, write, admin
Looking at something, changing something and changing who may do what are three different classes. A capability belongs to one, and says which.
2Risk tiers set the bar
The higher the risk, the stricter the rule. A high-risk action does not run on a grant alone: it needs an approval.
3No self-approval
The approval comes from someone else. A person cannot approve their own request.
4Denials explain themselves
A refusal says why, and it is written to the audit log. Nobody has to guess which rule said no.
5MCP goes through the gateway
MCP servers are reached through the gateway, not straight from the agent. They are held to the same decision as every other tool.
6Hooks on tools and models, failing closed
Your organisation can add hooks that admit or refuse every agent tool call and every model call: data-loss prevention, prompt-injection checks, secret scanning. A hook that cannot answer is a refusal.
7An identity for every agent
An agent holds its own grant, and that grant is intersected with its user’s. It never does more than either one allows.
8Your directory, your teams
Connect Entra or Google, and people and teams arrive as they are in your directory. Grants follow the org chart.
The work waits.
It does not restart.
When the decision comes back needs approval, the call is suspended into durable storage rather than failed and retried. A person answers, and the invocation is resumed exactly once — the claim is a compare-and-set, so two platform replicas cannot both re-dispatch it. An action whose outcome after the effect is genuinely unknown is never silently re-offered.
The asks that need you
land in one queue.
Approving a lowered sensitivity level, letting a new package go live, moving a connector, granting somebody access, clearing a listing for the store, releasing a held email — they all arrive in the same place, look the same, and are answered the same way. You can answer, take your answer back, or put it off. Nobody has to learn six inboxes.
1Several to agree, one to stop it
An ask can require a number of people to agree before it goes ahead — while a single refusal settles it on its own. That asymmetry is the point: a quorum should make approval harder, never make objecting harder.
2Ask a team, and it resolves to people
Address an ask to a team and it is expanded to the people in it at that moment, and kept. Someone who joins tomorrow is not silently added to a question already in front of others, and someone who leaves does not vacate a seat that was already counted.
3A team it cannot read is a refusal
If the directory cannot be reached, the ask is refused rather than sent to an empty audience — which would otherwise look exactly like a question awaiting an answer that can never come.
4A deadline that passes does not lose your answer
Deadlines say what they do. One closes the question for good; another simply drops it out of the everyday queue while leaving it answerable, so a late reply still counts instead of hitting a wall.
A record you can
re-derive.
Every capability invocation passes one router, and it records what it allowed and what it refused, each with the reason behind it. Your organisation's own record is searchable by the thing that was touched, by the permission that allowed it, and by the request it belonged to — and exportable as a pack you can hand to somebody.
The entries are chained together, and you can ask the platform to re-derive that chain and report any break. Deliberately, the rule for turning an entry into the bytes that get chained lives outside the service that writes the log: a record only the author can check is not evidence. Today the chain checks itself against whoever operates the installation; it is not yet anchored by an independent party.
Set policy once.
Everyone inherits it.
Define a role — "support agents may read customer records and update tickets" — and assign it to a team. Membership is not copied anywhere: the check walks the team and its sub-teams at the moment it runs, so adding someone covers them on their next call, and removing them from the team ends what that team gave them. Removing someone from the organisation withdraws their role assignments and clears the cached decisions that depended on them.
Reach is one question.
Ownership is the other.
Everything on this page decides how far an agent may reach. It says nothing about what happens to the things it reaches — who owns them, who they can be shared with and for how long, how sensitive they are, where they are allowed to run, and what happens when they have to be kept or destroyed. That is one model across every kind of thing the platform holds, and it has a page of its own.
Properties, not
promises.
Least privilege by default.
An agent acts with its owner's authority. That is what an agent gets when it declares nothing, and no tier setting raises it above the person it acts for.
An unknown answer is a no.
A ceiling that cannot be resolved, an aperture that cannot be read, a call that names no organisation — each is a refusal. Nothing is admitted because a check was unavailable.
Bound at the decision.
Every policy check is scoped to one organisation, and a request naming none is refused before the check is made. Queries carry the tenant with them.
Never handled by the caller.
Model traffic leaves through a single gateway. One service decrypts a stored provider credential; what a caller holds afterwards is an encrypted token that neither the caller nor that service can open again.
See agents put to work.
Control is invisible when it works. Follow a real process end to end and watch agents act with exactly the access they hold — and stop where a person has to answer.
At a glance
- pick a tier, not a policy
- no aperture stated ⇒ refused
- role + team, expanded at the check
- owner-bounded by default
- approvals suspend, resume once
- refusals carry their reason
- one queue for every human answer
- an audit chain you can re-derive