Agentic FabriqScope access to the customer associated with the active case.
The ticket defines the reachable customer; browsing beyond the case simply is not possible.
SOLUTIONS / Customer Support
Move from suggested answers to safely executed resolutions
Give support agents enough authority to resolve issues—without exposing customers or exceeding policy.
01 / IDENTITY02 / POLICY03 / AUDIT
01 / THE CONTEXTResolve the ticket.
Resolve the ticket.
Stay inside the customer’s account.
Support agents are increasingly expected to do more than draft responses. They may retrieve account data, change plans, issue credits, reset credentials, cancel orders, or update customer records.
- 40912Nadia A. — change planthe active caseResolves
- 40915Nadia A. — credit $40under the set thresholdResolves
- 40921Nadia A. — refund $1,250above the set thresholdEscalates
- 40903Priya S. — billing questiona different customerNot readable
- 40927Nadia A. — reply to customerexternal messageDrafts for review
support-agent works inside the case a support specialist is on, with that specialist’s own authority. Everything else stays shut.
02 / IN PRACTICE
Autonomy, with accountability.
- Sent09:12
ToNadia A. — the customer on this case
ZendeskReplacement dispatched, tracking attached
“Your replacement ships today — here is the tracking link, and the original charge is reversed.”
Allowed · the case decides which customer is reachable, and this is that customer
- Never written09:14
Toa second account, to “compare the two orders”
IntercomNothing to send
The other account’s order history never came back, so no draft quoting it ever existed — not a redacted message, an absent one.
Blocked · per-case scoping, even when the request is phrased helpfully
- Waiting09:21
ToNadia A. — refund above the specialist’s own limit
ZendeskRefund offer, addressed and ready
“We can refund this order in full.” Written, checked, and not sent: the amount is over the line set for this specialist.
Held · a supervisor decides; the customer sees nothing until they do
Three messages, one morning, one specialist’s authority. The difference between the first and the third is not what the agent judged safe — it is where the threshold sits for the person it is working for.
03 / WHAT CHANGES
Control, in the details.
Limit agent actions based on the human representative’s own authority.
The agent can do at most what the rep it assists could do — automation never exceeds the person behind it.
Decide which of refund, credit, cancellation and replacement an agent holds at all.
Each is its own action in the grant, so an agent can issue a credit and have no way to cancel an order — and only where the rep it assists could do the same.
Leave the high-risk cases to a person by leaving the action out.
An action the agent does not hold fails before it reaches the tool, so the case lands with a rep instead of resolving quietly.
Prevent cross-customer data leakage.
Per-case scoping means even a manipulated request cannot surface another account’s data.
Decide whether an agent may send externally at all, or only draft.
Send and draft are separate actions in the grant: an agent given only the draft action has no way to reach the customer directly.
Preserve the evidence and reasoning behind each resolution.
Every resolution carries what was read, what was done, and whose authority it ran on — ready for any dispute.
THREE LAYERS. ONE DECISION.
The boundary travels with the work.
Explore the context attached to every request.
What is this agent allowed to do?
support-agent has a defined purpose and a bounded set of tools.
Whose authority travels with it?
The request acts for support specialist, using that person’s permissions.
Where does the action land?
The policy applies to the requested action within Support desk, before the tool executes.
04 / WAYS TO PUT IT TO WORK
Built for your real workflows.
01A support agent that issues a refund only where the rep it assists could.
One deployment, as many levels of authority as you have reps: the refund action has to be in both the agent’s grant and that rep’s own permissions.
Identify→Authorize→Record
02An account-recovery agent that can read the account but not change credentials.
The credential-reset action is left out of the grant, so recovery gathers the facts and a rep makes the change.
Identify→Authorize→Record
03A troubleshooting agent that can read telemetry but cannot change production configuration.
Read access to diagnostics comes without any path to production configuration.
Identify→Authorize→Record
04A customer-success agent that updates CRM records only for assigned accounts.
Updates apply only to the rep’s assigned accounts, keeping the CRM clean and territorial boundaries intact.
Identify→Authorize→Record
QUESTIONS
A closer look.
Do we have to change our support stack to use this?+
No. Fabriq sits between your agents and the helpdesk, billing, and CRM systems you already run. Tickets, refunds, and account changes keep flowing through the same tools — each action is just checked against the agent’s grant and the rep’s own permissions first.
Who is accountable when an agent resolves a case?+
The human representative the agent acts for. The agent’s authority is capped at that rep’s own, and every action records the rep, the agent, the action and the verdict — so disputes resolve from evidence.
What happens when a rep leaves or changes teams?+
Access follows the person — grants resolve org → team → member, so a team change updates authority, and revoking a session cuts their agents off immediately.
Can authority differ per representative?+
Yes. The agent’s reach is capped at the authority of the person it assists: which actions it may take and which accounts it may reach resolve per representative and per case, so automation never quietly exceeds the human behind it.
Can we stop an agent issuing refunds at all?+
Yes — leave the refund action out of its grant and it never appears in the tool list, while lookups and replies stay instant. The whole exchange lands in the record either way.
How do agents reach our support tools?+
Through the hub — prebuilt connectors plus OpenAPI import for your internal systems, with credentials held in the vault instead of pasted into bot configs.