Agentic FabriqGive every agent its own identity — including each running copy of the same agent.
Agents stop hiding behind shared service accounts; each one is a distinct identity your access rules can point at, audit, and revoke.
SOLUTIONS / Identity & Access Management
Make agent identity part of your existing IAM architecture
Fit agents into the identity architecture you already have — without forcing them into human or service accounts.
01 / IDENTITY02 / POLICY03 / AUDIT
01 / THE CONTEXTNot a user.
Not a user.
Not a service account.
An agent is not simply a user, service account, or application. It may act for several people, invoke other agents, change tools during a workflow, and operate with different authority in each context.
- Person
A. Riverafrom your directory: Finance, manager - Agentprocurement-agentacts for A. Rivera, within her permissions
- Sub-agentinvoice-readergiven one narrow task, not the coordinator’s reach
- Request
QuickBooks · read one invoiceresolved against A. Rivera’s permissions, at call time
Each row is a distinct identity your access rules can point at. The hand-off is recorded with its limits, so the authority behind the last step is still traceable to the first.
02 / IN PRACTICE
Autonomy, with accountability.
ILLUSTRATIVE · ONE GROUP CHANGE, SAME THREE REQUESTSprocurement-agent, acting for A. Rivera · registration untouched
BeforeTue 17:57
A. Riveradirectory groupsAP approversFinance readers
- Read a supplier invoiceAllowedHer group carries the read; the agent stays inside it.
Open a procurement requestBlockedNot hers yet, so not the agent’s either.
Release a paymentHeldA checkpoint, not a permission — a person decides.
17:58The directory moves her to Procurement.
One change in your IdP. No redeploy, no new grant, no ticket for the agent’s owner.
AfterTue 17:59
A. Riveradirectory groupsAP approversProcurement
- Read a supplier invoiceBlockedThe group went; the agent’s reach went with it, on the next call.
- Open a procurement requestAllowedHer new group opens it — for her, and so for her agent.
- Release a paymentNot offeredUnchanged: the agent was never granted it, in either group.
The agent was not touched on either side of 17:58. What changed is whose authority it is carrying — resolved at the moment of the call, from the same directory your people sign in with.
03 / WHAT CHANGES
Control, in the details.
Bind the agent to an owner, application, purpose, and approved capabilities.
Identity carries accountability metadata, so every access decision can reference who is responsible and what the agent is for.
Record who handed authority to whom, and for what.
Every hand-off is recorded — user to agent, agent to sub-agent — with explicit limits instead of an implied full grant.
Apply user-specific policy to a shared agent.
A single agent serving hundreds of employees evaluates each request against that employee’s own permissions, not a one-size-fits-all role.
Resolve access from the human identity and the agent identity together.
Every call carries both, and the reachable set is where their grants overlap — which person, acting through which agent, with the smaller of the two winning.
Keep the hand-off trail across multi-agent workflows.
When a coordinating agent hands work to a specialist, the originating user’s authority and its limits travel with the task.
Inherit relevant user and group changes from existing identity systems.
Role changes, group moves, and departures flow from your IdP into agent permissions automatically, with no parallel directory to maintain.
Avoid forcing every agent into a human account or broad service account model.
Agents get an identity type that fits how they actually behave, instead of distorting your workforce or service-account models.
THREE LAYERS. ONE DECISION.
The boundary travels with the work.
Explore the context attached to every request.
What is this agent allowed to do?
identity-agent has a defined purpose and a bounded set of tools.
Whose authority travels with it?
The request acts for identity administrator, using that person’s permissions.
Where does the action land?
The policy applies to the requested action within Identity directory, before the tool executes.
04 / WAYS TO PUT IT TO WORK
Built for your real workflows.
01One procurement agent serving hundreds of employees with different purchasing limits.
Each purchase request is evaluated against the requesting employee’s own limit, so one shared agent enforces hundreds of different ceilings.
Identify→Authorize→Record
02A manager temporarily lending part of their own authority to an agent for one workflow.
The grant covers that workflow and expires on its own instead of becoming standing authority.
Identify→Authorize→Record
03A coordinating agent assigning a narrow task to a specialist sub-agent.
The sub-agent receives only what its narrow task needs — never the coordinator’s full permissions or the user’s full token.
Identify→Authorize→Record
04Revoking a user’s agent access when their department or role changes.
Role changes propagate to every agent acting for that user, narrowing their authority the moment the org chart moves.
Identify→Authorize→Record
QUESTIONS
A closer look.
How does Fabriq fit our existing IAM stack?+
It drops in beside your identity provider rather than replacing it. Users, groups, and roles stay where they are; Fabriq adds the layer IAM does not model — agent identities bound to human ones through explicit, scoped, per-user delegation.
Does an agent keep its authority forever once granted?+
No. Grants carry limits and an expiry. They can be tied to one task or workflow, and they shrink or end automatically when the underlying user’s role changes or their relationship ends.
How fast does revocation propagate?+
Session revocation takes effect now, not at token expiry — and disabling an agent org-wide means its next call fails closed.
Can one shared agent carry different policy per user?+
Yes. A single deployed agent evaluates every request against the permissions of the person it is acting for, so hundreds of employees can share an agent while each gets exactly their own access and limits.
Do agents get first-class identities?+
Yes — every agent is registered with an owner and scopes, and every action carries two identities: the agent’s and the signed-in user it acted for.
How are grants structured?+
Default-deny and additive: org, then team, then member, with reusable scope sets and per-user overrides — an agent sees only the intersection of its grants and the user’s.