Every agent tied to the employee who runs it.
Actions stay attributable; permissions inherit from the employee’s own role.
Every copilot gets an owner, a permission set, and an audit trail — before it touches a real system.
Agents are already inside: drafting from Gmail, querying the CRM, touching databases. Nobody approved most of them — and nothing is watching.
mail-draftDrafting repliescrm-lookupLooking up accountsdigest-botSummarising channelsworkplace-agentReading team documentsIllustrative roster. A registered agent carries an owner, a permission set, and a record of everything it did.
The agent starts under Dana’s own identity — her role, her teams, her connected tools. Nothing of its own.
The sales team’s folder is hers to open, so it is the agent’s to read. Allowed, and written to the trail with both names on it.
A draft in Dana’s own mailbox. The agent never holds her mail credential — it is attached on Fabriq’s side for the call.
Dana is not in that team, so the agent acting for her is not either. Stopped before the call leaves Fabriq.
A named human approver has to say yes first. Nothing leaves the workspace while the request waits.
One record for all of it: who asked, which agent acted, what it touched, and how each call came out.
Illustrative day · effective access = the agent’s grants ∩ Dana’s own permissions.
Actions stay attributable; permissions inherit from the employee’s own role.
Per agent, per user, per action — the full permission model, enforced on every call.
Who triggered it, what was accessed, and what happened — every time.
Rule-breaking actions are blocked up front, not flagged afterwards.
Okta, Azure AD, Google Workspace — no infrastructure redesign.
Disable an agent org-wide and its next call fails closed — no key rotation scramble.
Which agent, for which person, against which resource. Decided before anything runs.
Swipe to explore all six tools →
| AGENT × TOOL | 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 |
sales-agent → Gmail, acting for Dana. Both the agent grant and the user’s permission allow this tool.
Explore the context attached to every request.
workplace-agent has a defined purpose and a bounded set of tools.
The request acts for employee, using that person’s permissions.
The policy applies to the requested action within Workspace, before the tool executes.
At registration — each agent binds to its owner, inherits their permissions, and every action it takes carries both identities.
No — Fabriq drops in between the agents people already use and the systems those agents touch. Workflows stay; controls attach underneath.
Yes — grants go down to single actions, and sensitive ones can be held for human approval while everyday calls stay fast.
Their agents lose access automatically, and the record of everything those agents did stays intact for review.
Whatever your organization connects through the hub — Microsoft 365, Google Workspace, Slack, and GitHub prebuilt, plus your own APIs, MCP servers, and Postgres behind guardrails.