Response engine
Act automatically on risk by quarantining an agent, revoking a key, or raising an alert when a rule fires.
Policies decide one call at a time. The response engine reacts to what an agent is doing over time: when a rule's conditions are met, it takes an action (quarantine the agent, revoke its keys, or raise an alert) without a human in the loop. Rules are managed in the dashboard (Detect → Response) or the admin API.
Anatomy of a rule
A rule is conditions → action, with a posture and rate limit:
| Field | Notes |
|---|---|
toolPattern | Glob over the tool name; default *. |
riskThreshold | Fire at or above this risk (0–100). |
signalCategory | secret · pii · destructive · injection · egress · bot_spoof · rate_abuse · supply_chain. |
detector | A custom content detector id. |
requireCritical | Only when a live secret/key was detected. |
windowSeconds + minEvents | Sustained: N matching events within a window. |
action | quarantine_agent · revoke_key · open_alert · notify. |
severity | low · medium · high · critical (default high). |
mode | monitor (simulate) or active (enforce). Default monitor. |
cooldownSeconds | Won't re-fire on the same agent within this window (default 3600). |
priority · enabled | Lower priority first; rules are toggleable. |
A rule needs at least one condition. Most rules watch the tool-call / card path, but two predicates move a rule onto a different path:
onKillChain: true: fires only when a multi-step kill chain is detected (read a secret → exfiltrate it), not on single calls.mlThreatClass/mlRiskThreshold: fires only after the ML assessment of a call completes.
Actions
| Action | Effect | Reversible |
|---|---|---|
quarantine_agent | Lock the agent in the kill switch: every call is denied. | Yes, via POST /api/response-actions/{id}/undo. |
revoke_key | Revoke all of the agent's API keys immediately. | No. |
open_alert | Raise an auto_response alert to the dashboard and webhooks. | - |
notify | Send a notification over a configured channel. | - |
create_ticket | Open a Jira issue or ServiceNow incident in every enabled connection. | - |
invoke_webhook | POST an HMAC-signed payload to every enabled SOAR webhook (Tines, Torq, n8n). | - |
Roll out in monitor first
A rule is born in monitor: it records what it would have done, with no
effect. Watch it against live traffic, then arm it by setting mode: "active"
(PATCH /api/response-rules/{id}).
SOAR and ITSM (Team plan)
A SOC will not adopt a new alert console, so AxioRank can deliver into the queue
you already run. Add a connection under Response → SOAR / ITSM connections,
then arm a rule with the create_ticket or invoke_webhook action:
- Jira and ServiceNow receive a ticket (issue / incident) with the rule name, the agent, the subject, severity, risk, and the signal categories.
- A generic webhook receives a signed
response.actionJSON payload, so Tines, Torq, n8n, or any HTTP receiver can run your own playbook. Verify thex-axiorank-signatureHMAC exactly as you do for developer webhooks.
Connection secrets are write-only: the API never returns them. Use the Test
button to confirm credentials before arming a rule. SOAR actions need the
soar plan entitlement on top of armed response; a rule that uses them on a
plan without it records skipped (plan_gated) instead of acting.
Cross-tenant threat intel
Verifying an external agent's card is stronger with signal from the whole network.
Participation is opt-in on both sides (workspace setting threat_intel_enabled):
opting in both contributes your anonymized flags and lets network signal enrich
your decisions. Once five or more distinct workspaces have independently
flagged the same identity, it surfaces as enrichment in every participating
workspace's verify-card decision and on the public trust
registry.
That k of 5 anonymity floor means no single workspace's activity is ever visible: an identity stays below the floor until at least five distinct tenants flag it, your flags are never attributable to you, and the lookup that enriches your decisions excludes your own workspace.
Webhooks
The engine emits developer webhook events you can subscribe to:
kill_chain.detected: a multi-step attack sequence was recognized.agent.quarantined: an agent was locked (includessource: "auto_response").
Next steps
- Webhooks: subscribe your services to these events.
- Policies: per-call verdicts that complement automated response.
- Content-inspection engine: the signals rules fire on.