Agentic FabriqGive each agent a persistent identity, owner, purpose, and set of capabilities.
Agents register once with Fabriq and carry that identity across every tool call, so nothing runs anonymously or under a borrowed service account.
SOLUTIONS / AI / Engineering
Build agents that can safely take action
Ship production agents without rebuilding identity, permissions, and governance into every application.
01 / IDENTITY02 / POLICY03 / AUDIT
01 / THE CONTEXTWiring a model to tools
Wiring a model to tools
is the easy half.
AI teams can quickly connect a model to tools. The harder problem is determining what each agent should be allowed to do once it begins operating on behalf of real users.
GitHubread · open a pull request
Snowflakeread approved datasets
Linearcomment on its own issues
Slackpost to one channel
Salesforcenot in scope
Scopes resolve per request against the person the agent is acting for, so the same registration can reach further for one engineer than for another.
02 / IN PRACTICE
Autonomy, with accountability.
$ agent run “pull Q2 signup counts by plan and open the follow-up PR”
- 10:02:11
snowflake.query · approved_datasets.signupsallowedRan on a short-lived credential the agent never sees. - 10:02:19
snowflake.export · customer_contactsblockedRestricted data: outside the grant, so no call left Fabriq. - 10:02:26
github.pull_request.open · analytics/etlallowedInside the repositories this agent was registered for. - 10:02:31
github.deployment.create · productionnot offeredNever granted to this agent, so the tool was not in the list it was handed.
$
03 / WHAT CHANGES
Control, in the details.
Apply different permissions to the same agent depending on the user it represents.
One deployment serves the whole team: reach resolves at request time from the acting user’s role, not from whatever the integration was granted.
Keep what an agent may do out of prompts and application code.
Grants live beside the agent’s registration where they can be read and changed — narrowing one never means redeploying the agent or rewriting a prompt.
Leave the sensitive actions out of the grant entirely.
An action the agent was never granted does not appear in the tool list it is handed, so there is nothing to intercept at call time — and if it asks anyway, the refusal is recorded with the attempt.
Hold the credentials so agents never touch long-lived secrets.
The agent requests access per call and receives a short-lived, limited credential — there is no API key in the prompt, the code, or the model’s context.
Trace any action back through the prompts, tool calls, and permissions that produced it.
Every step is linked in one record, so debugging or an incident review starts from the action and walks backward in minutes.
Reuse the same controls across models, frameworks, applications, and integrations.
Controls attach to the agent’s identity, not the stack — swap the model or framework and the same policies keep enforcing.
THREE LAYERS. ONE DECISION.
The boundary travels with the work.
Explore the context attached to every request.
What is this agent allowed to do?
research-agent has a defined purpose and a bounded set of tools.
Whose authority travels with it?
The request acts for engineer, using that person’s permissions.
Where does the action land?
The policy applies to the requested action within Approved datasets, before the tool executes.
04 / WAYS TO PUT IT TO WORK
Built for your real workflows.
01An internal research agent that can search approved systems but cannot export restricted documents.
Read scopes cover the approved systems only; export and external-share actions are blocked at the gateway, not left to the prompt.
Identify→Authorize→Record
02A coding agent that may open pull requests but cannot merge or deploy.
The agent is granted branch pushes and pull requests and nothing else. Merge and deploy are not in the tool list it receives, so those stay with an engineer.
Identify→Authorize→Record
03A data agent that can query approved datasets while filtering rows and fields based on the requesting user.
Row- and field-level filters come from the requesting user’s own permissions, so two employees asking the same question see only their own slice.
Identify→Authorize→Record
04A customer-service agent that can issue a refund only where the rep it acts for could.
The refund action has to sit in both the agent’s grant and that rep’s own permissions. A rep without refund authority lends none to the agent, and every resolution is recorded with both identities.
Identify→Authorize→Record
QUESTIONS
A closer look.
Do we have to rebuild our agents to use Fabriq?+
No. Fabriq is a permissions layer that drops in between your agents and your systems. Agents keep their model, framework, and code; you register their identity and route tool calls through Fabriq, and policy, credentials, approvals, and logging attach at that layer.
What happens when an agent tries something outside its grant?+
The call is refused before it reaches the tool. The attempt is logged with full context — agent, user, resource, and which check stopped it — so teams can tune the grant rather than guess.
Where do our credentials live?+
In Fabriq’s vault. They’re injected server-side at call time and refresh automatically before expiry — the agent process never holds a raw key.
Can we choose what each agent can access and do, per user?+
Yes — that is the core of it. Reach resolves at request time from the acting user’s identity, so the same deployed agent can query a dataset for one engineer and be refused the same query for another. You decide what is reachable and what is allowed, per user, per action.
How do we connect internal APIs and databases?+
Import an OpenAPI spec and it becomes agent-usable tools automatically, register an MCP server, or connect Postgres with read-only guardrails — internal systems stay behind your firewall over an outbound-only tunnel.
What do we get for debugging and review?+
One trail across every agent and tool — who asked, which agent acted, what it touched, and the verdict — queryable in the dashboard and exportable to your own tooling.