Agentic FabriqThe agent can never exceed the person.
Every call resolves to the overlap of the agent’s grants and the acting user’s own access — the smaller set always wins.
PLATFORM / Permissions & Scopes
One agent. A different boundary for every person it acts for.
An agent reaches the overlap between what it was granted and what the person it is acting for can already do — resolved per request, enforced at the tool-call boundary, never in the prompt.
01 / IDENTITY02 / POLICY03 / AUDIT
01 / THE CONTEXTTwo grants.
Two grants.
One request. The smaller set wins.
“This agent can use Slack” is not a permission model — a service account gives every agent the same access, for every person, all the time. The intern’s request and the CFO’s request come out of the same key.
THE AGENT’S GRANTS
- crm.account.read
- crm.account.write
- crm.export
- refunds.issue
THE PERSON IT ACTS FOR
- crm.account.read
- crm.account.write
- crm.export
- refunds.issue
EFFECTIVE, THIS REQUEST
- crm.account.read
- crm.account.write
- —
- —
Illustrative scopes. The smaller set always wins — resolved per request, at the tool-call boundary.
02 / IN PRACTICE
The right access. In every context.
TWO SETS · ONE REQUEST AT A TIMEIllustrative · sales-agent acting for an Account owner, in the CRM
THE AGENT’S GRANTSTHE PERSON’S OWN ACCESS
crm.export_allin the grant onlycrm.account.readin bothcrm.owner.changein both · heldrefunds.issuethe person only- AllowedRead an assigned account
crm.account.readIn the overlap: the agent was granted it and the account owner can already do it. The call goes out on a vault-held credential.
- BlockedExport all customer records
crm.export_allIn the agent’s grant, outside this person’s own access — so outside the overlap. The smaller set wins and the export never runs.
- HeldChange account ownership
crm.owner.changeInside the overlap, but a named human approver has to say yes first. Nothing changes hands while the request waits.
Illustrative scopes · nothing is reachable until it is in both sets.
03 / WHAT CHANGES
Control, in the details.
Per-user overrides on shared agents.
Read-only for one person, read-write for another — one agent, one deployment.
Off-limits tools don’t exist.
The tool list is built per user, so an agent is never even offered what that person can’t do.
Down to single actions.
Grant or deny specific actions per user — not just whole tools.
Default-deny, additive grants.
Nothing is reachable until granted — org, then team, then member.
Reusable scope sets.
Define “support tools, read-only” once; apply it everywhere.
02 / THE CONTROL LAYEREvery action checked
Every action checked
against policy.
Which agent, for which person, against which resource. Decided before anything runs.
Swipe to explore all six tools →
| AGENT × TOOL |  Gmail |  Slack |  Drive |  GitHub | DBDatabase | $Payments |
|---|---|---|---|---|---|---|
| sales-agentfor dana@acme | ||||||
| support-botfor dana@acme | ||||||
| data-pipelinefor dana@acme | ||||||
| finance-agentfor dana@acme | ||||||
| research-agentfor dana@acme | ||||||
| ops-agentfor dana@acme |
✓ Allowed
sales-agent → Gmail, acting for Dana. Both the agent grant and the user’s permission allow this tool.
● ALLOW × BLOCKEDIllustrative policies · effective access = agent grants ∩ user permissions
THREE LAYERS. ONE DECISION.
The boundary travels with the work.
Explore the context attached to every request.
What is this agent allowed to do?
sales-agent has a defined purpose and a bounded set of tools.
Whose authority travels with it?
The request acts for account owner, using that person’s permissions.
Where does the action land?
The policy applies to the requested action within CRM, before the tool executes.
QUESTIONS
A closer look.
Where are permissions enforced?+
At the tool-call boundary, outside the model — a clever prompt can ask for anything, but it can’t get past the gate.
What happens if the agent is granted more than the user has?+
The extra grant does nothing. Permission is the overlap of the two, so an agent allowed to issue refunds still cannot issue one for a person who has no refund access of their own.
Who sets the permissions?+
The people accountable for the systems — admins define org and team grants, scope sets cover the common cases, and per-user overrides handle the exceptions.
Can the same agent differ per person?+
That is the default. Every request resolves against the acting user’s own access and overrides, so one deployment behaves differently for a team lead than for a new hire. No forked agents, no lowest common denominator.
What does a blocked call look like?+
Usually nothing: off-limits tools aren’t even visible to the agent. A call that arrives anyway is refused before it reaches the system.
Do changes require a redeploy?+
No — policy is read live on each request. Tighten a grant and the very next call obeys it; there is nothing to ship or restart.