Agentic FabriqSign in through your IdP.
Okta and any OIDC-compatible provider plug straight in.
PLATFORM / Enterprise Identity
Your IdP, your org structure, your revocation button
Sign-in through your identity provider, isolated per tenant, revocable in one action.
01 / IDENTITY02 / POLICY03 / AUDIT
01 / THE CONTEXTYour directory decides
Your directory decides
who an agent can be.
“We’ll add SSO later” is where agent pilots go to die in security review.
- ORGNorthwinddefault deny
- TEAMEngineeringgranted
- MEMBERAlex Rahmansigned in through the IdP · inherits the team grant
- MEMBERJo Fletcheroffboarded in the IdP · no acting identity
- TEAMFinancegranted
- MEMBERPriya Menonper-user override · no delete scope
- TEAMEngineeringgranted
Your provider owns who exists; Fabriq resolves what they may do — org, then team, then member, and anything not granted is denied.
02 / IN PRACTICE
Your people. Your source of truth.
ONE IDENTITY · EITHER SIDE OF ONE EDITIllustrative · workplace-agent acting for Jo Fletcher, Engineering
session open · grants inherited from the group- Open an authorized sessionAllowed
Signed in through your provider, in the Engineering group. The agent acts as Jo, with Jo’s own reach.
- GitHubRead the team’s repositoryAllowed
The grant resolves org, then team, then member — and Engineering has this one.
- Elevate to administratorHeld
A named human approver has to say yes first. The role is unchanged while the request waits.
session cut · no identity to act for- Resume the session already openRefused
Cutting the session ends it there and then — it does not run on until a token expires.
- GitHubRead the same repositoryRefused
The group membership is gone, so the grant it carried is gone with it. Nothing to inherit.
- The elevation still waitingRefused
An identity that no longer exists cannot be approved into a bigger one. The request dies with it.
Illustrative · your provider owns who exists; nothing here keeps a second copy of that answer.
03 / WHAT CHANGES
Control, in the details.
Standards-based SSO under the hood.
Standard token exchange behind sign-in — nothing homegrown to review.
Revocation that means now.
Cut a session and it dies immediately — not at token expiry.
A separately hardened admin plane.
Platform admin sits behind its own auth, TOTP, and recovery codes.
Multi-tenant from day one.
Organizations, teams, and invitations are first-class from the start.
Permissions that follow your org chart.
Grants resolve org → team → member, default-deny, with per-user overrides.
IDENTITY LIFECYCLE
A lifecycle, carried through.
Okta / OIDC
maya@ · session⬡ Agentic Fabriqyour IdP · per-tenant realm
her agents · scoped access
revoke → dead now, not at expiry
SIGN IN THROUGH YOUR IDP — REVOKE A SESSION AND IT DIES NOW, NOT AT EXPIRY
THREE LAYERS. ONE DECISION.
The boundary travels with the work.
Explore the context attached to every request.
What is this agent allowed to do?
workplace-agent has a defined purpose and a bounded set of tools.
Whose authority travels with it?
The request acts for active employee, using that person’s permissions.
Where does the action land?
The policy applies to the requested action within Identity provider, before the tool executes.
QUESTIONS
A closer look.
Does it work with our identity provider?+
Okta and OIDC-compatible providers connect directly — people sign in the way they already do, and agents operate under those identities.
Is admin access separated from everyday use?+
Yes — platform administration is a separately hardened plane with its own authentication, TOTP, and recovery codes.
Can we model multiple teams or subsidiaries?+
Yes — organizations contain teams with invitations and grants at each level, and permissions resolve org → team → member on a default-deny basis.
How fast can we revoke access?+
Immediately — session revocation takes effect now, not at the next token expiry. Disabling an agent covers the non-human side just as fast.
Do agents get identities too?+
Yes — every agent is registered with an owner and scopes, and every action carries both the agent's identity and the signed-in user it acted for.