SOLUTIONS / Security

Give agents only the access they need, at the moment they act

Prevent AI agents from turning legitimate access into unauthorized action.

Get a demoExplore the workflow ↓
01 / IDENTITY02 / POLICY03 / AUDIT
FABRIQ / RIPPLESCOPE · APPROVAL · CONTAINMENT
Only what this call needs.FABRIQ / SECURITY OPERATIONS
01 / THE CONTEXT

A call is easy to log.
Harder to explain.

Traditional security tools can show that an API call occurred. They often cannot explain which agent initiated it, whose authority it used, why it took the action, or what sequence of model decisions and tool results led to it.

AN EXAMPLE REQUEST, NARROWEDPagerDuty
  1. What the connected account can reachevery service, every incident, standing access
  2. What security-agent is grantedthe on-call queue it was registered for
  3. What this request receivedone incident, read only, for this call

Connecting an agent hands it a defined slice of an analyst’s authority, never the whole token — and the credential itself stays in the vault. Containment revokes the agent’s grant while the analyst keeps working.

02 / IN PRACTICE

Autonomy, with accountability.

ILLUSTRATIVE · ONE INCIDENT, ONE NIGHTsecurity-agent, acting for the analyst on call
  1. 02:41

    incident.ioOpens the incident it was paged to.

    Assigned to the analyst on call · allowed
  2. 02:43

    DatadogReads telemetry for the affected service.

    Read, on the analyst’s own access · allowed
  3. 02:44

    ConfluenceReaches for a restricted investigation space.

    Nothing happened · blocked
  4. 02:46

    SlackPosts what it found to the incident channel.

    One channel, the one in scope · allowed
  5. 02:58

    GitHubProposes containment: revoke the exposed deploy key.

    Waits for the analyst to say yes · held

The line at 02:44 is the one to read.

A tool log can only show the calls that happened. Here the call that did not happen has a mark of its own — which agent asked, whose authority it was carrying, what it wanted, and that it never left the layer. The four minutes on either side of it are the same record, so the sequence reads end to end without joining four systems together first.

03 / WHAT CHANGES

Control, in the details.

01

Identify every agent and associate it with an owner and approved purpose.

Unowned automations disappear: anything acting on your systems has a registered identity, a responsible human, and a stated purpose to check behavior against.

02

Grant only the access each action actually needs.

Grants are expressed as specific actions on specific resources, so an agent that reads tickets cannot also edit them just because the API allows it.

03

Prevent an agent from using a user’s full access simply because the user connected it.

Delegation is scoped: connecting an agent hands it a defined slice of your authority, never your whole token.

04

Grant the specific actions on the specific resources, and nothing adjacent.

A grant names an action and what it may touch, so an agent that reads one system’s records has no route to another — the reach is drawn before the call, not judged during it.

05

Fail an out-of-bounds action closed, loudly, and on the record.

It neither proceeds nor disappears: the call is refused before it reaches the tool, and the attempt is written with the agent, the acting user, and which check stopped it.

06

Detect unusual behavior across users, tools, and workflows.

Because every action routes through one layer, deviations from an agent’s normal pattern stand out against a complete baseline.

07

Reconstruct the chain of events behind an incident.

From any suspicious action, walk back through the tool calls, the delegation, and the triggering input that produced it.

08

Contain a compromised agent without disabling the underlying user.

Revoke the agent’s identity and grants while the employee keeps working — containment no longer means locking a person out of their job.

THREE LAYERS. ONE DECISION.

The boundary travels with the work.

Explore the context attached to every request.

What is this agent allowed to do?

security-agent has a defined purpose and a bounded set of tools.

04 / WAYS TO PUT IT TO WORK

Built for your real workflows.

01Blocking an agent from sending sensitive files to an external domain.

Destination-aware policy stops the send at the tool-call layer, even if the agent was manipulated into attempting it.

Identify→Authorize→Record
02Keeping production infrastructure out of an agent’s reach entirely.

Infrastructure actions are left out of the grant, so the agent can investigate and report but a possible outage stays in the on-call engineer’s hands.

Identify→Authorize→Record
03Preventing a support agent from reading customers outside its assigned region.

Resource scoping pins the agent to its assigned region’s customers, so a crafted request cannot widen its reach.

Identify→Authorize→Record
04Limiting a finance agent to approved counterparties and transaction thresholds.

Allow-listed counterparties and amount ceilings are enforced per transaction, independent of what the model decides to try.

Identify→Authorize→Record
QUESTIONS

A closer look.

Do we have to re-deploy agents behind a new gateway?+

No rebuild is required. Fabriq sits between agents and your systems — existing agents route their tool calls through it and immediately pick up action-level access limits and a complete action record.

How does Fabriq handle prompt injection?+

By assuming it will happen. Permissions are enforced outside the model at the tool-call layer, so a manipulated agent can attempt an unsafe action but cannot execute it — the scope check does not read the prompt, it reads the action.

Can we keep the riskiest actions away from agents entirely?+

Yes — permissions go down to single actions, so the risky ones are simply never granted. They do not appear in the tool list an agent is handed, while routine calls keep flowing.

Can we scope agents per user instead of per integration?+

Yes. The integration stops being the unit of access. Every request is evaluated against the acting user and the specific action, so one connected tool no longer means one broad grant shared by everyone who uses it.

What lands in the audit trail?+

Every governed call: the person who asked, the agent that acted, the tool, the action, and the verdict — one schema across everything, exportable to your SIEM.

How do we contain a compromised agent?+

Disable it org-wide and its next call fails closed. There’s no credential on the agent’s side to steal — secrets stay in the vault and attach server-side.

YOUR NEXT CHAPTER

Give security
room to move.

See Fabriq in action
Policy FirewallEnterprise IdentityAudit Trail