Do we have to rebuild our agents to use Fabriq?

No. Fabriq is a policy 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.

Can we choose what each agent can access and do, per user?

Yes — that is the core of it. Policy 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.

What happens when an agent tries something outside its policy?

The call is blocked or held for approval before it reaches the tool. The attempt is logged with full context — agent, user, resource, and the policy that stopped it — so teams can tune policy rather than guess.

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.

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.

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.

Department · AI / Engineering

Build agents that can safely take action

Ship production agents without rebuilding identity, permissions, and governance into every application.

Get a demo

The problem

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.

Without a shared policy layer, every engineering team must independently build authentication, credential handling, authorization, approvals, and audit logging. Policies become embedded in prompts and application code, making them difficult to review, update, or reuse.

Agentic Fabriq gives developers a common infrastructure layer for agent identity and access. Engineers define the agent, declare its capabilities, and route tool calls through Fabriq. Fabriq evaluates each action against the current user, agent, resource, purpose, and organizational policy before allowing it to proceed.

Live workflow

See a real workflow, governed

Every agent below carries its own identity and acts for a real user. Watch every tool call route through Fabriq — then edit the workflow yourself.

A PR triage agent reads a failing issue, opens a pull request against the fix, and posts a summary to the team channel — merges to main always need a human.

agent: pr-bot-01

CI failure / issue filedGitHub Actions

PR Triage Agentpr-bot-01 · for: dana@acme.com

Agentic Fabriqidentity · policy · audit

GitHubopen PR against fix branch

Slackpost PR summary

Drag nodes, draw connections, add tools — every agent action routes through Fabriq. Try wiring the agent straight to a tool.

The stakes

Why this is hard today

01Every team building an agent rebuilds the same plumbing — auth, secrets, approvals, logging — slightly differently each time.
02The rules live in the prompt, so a clever input or a model mistake can talk the agent right past them.
03One agent serves the whole team through one over-powered credential, so a mistake by anyone risks everyone’s access.
04When something breaks in production, there’s no thread connecting what the model decided to what the tools actually did.

Capabilities

How Fabriq helps AI and engineering teams

Give 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.

Apply different permissions to the same agent depending on the user it represents.One deployment serves the whole team: policy resolves at request time from the acting user’s role, not from whatever the integration was granted.

Separate business policy from prompts and application code.Rules live in the policy layer where they can be reviewed and versioned — changing a threshold never means redeploying the agent or rewriting a prompt.

Add approval steps for sensitive or irreversible actions.Declare which actions pause for a human; Fabriq holds the tool call until a named approver confirms, and the decision is recorded with the action.

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, approvals, 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.

In practice

Example workflows

approval: human approval

An 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 policy layer, not left to the prompt.

approval: human approval

A coding agent that may open pull requests but requires approval before merging or deploying.

The agent’s token can push branches and open pull requests, while merge and deploy actions hold for a named engineer’s approval.

approval: human approval

A 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.

approval: human approval

A customer-service agent that can draft resolutions but only issue refunds within defined thresholds.

Refunds under the threshold execute immediately; anything above it routes to a person, and every resolution is logged with its approver.

Business value

Faster production deployments, less duplicated security work, and fewer delays during enterprise security review.

Questions

Build agents that can safely take action

See a real workflow, governed

Why this is hard today

How Fabriq helps AI and engineering teams

Example workflows

Common questions