What Did the Agent Try to Do?

When an AI agent does something it shouldn't in prod, the post-mortem question is always the same. Most teams can't answer it.

I. The question after the incident

What did it try to do, and why was it allowed or stopped?

The answer is usually scattered across SDK wrappers, vendor dashboards, and whatever the framework chose to log. Each of those sees a slice. None of them recorded the decision itself: which policy applied, and what the outcome was.

II. A record of every decision

GrubX sits in front of your agents' tool calls and writes down each decision as it is made:

Every action. The agent, the tool, the operation, which policy fired, and whether it was allowed, blocked, or held for approval.
A tamper-evident audit chain. Records are hash-chained, so you can verify them and export them.
A kill switch per agent. Effective in seconds.

III. What it looks like

This replay is from a demo run. A refund over the threshold is held for approval and released by a reviewer. Then a delete, a PII email to an outside address, and a refund over the daily limit are all blocked. Finally, one agent is killed mid-run.

Seq	Agent	Action	Decision	Policy
#03	demo-agent	stripe.refund.createwithin policy	ALLOW	—
#04	demo-agent	stripe.refund.createTransaction of $100 or more needs approval	APPROVAL	transaction-limits.approval
#07	demo-agent	stripe.refund.createreleased by reviewer@acme.test	ALLOW	—
#09	demo-agent	stripe.refund.createAgent would exceed its $500 daily transaction limit	BLOCK	transaction-limits.daily
#10	demo-agent	crm.delete_customerDestructive operation (delete, drop, destroy)	BLOCK	destructive-actions
#13	demo-agent	email.send_emailSession read personal data; external send blocked	BLOCK	pii-egress.session
#14	demo-agent	crm.purge_inactiveDestructive operation (delete, drop, destroy)	BLOCK	destructive-actions
#63	ops-agent	stripe.customer.retrievekill-switch	BLOCK	kill-switch

✓ verified · audit chain, 63 events · head c96bf3fd87372f64…

IV. The same thing, as data

Under the table is a plain JSON Lines export. One line per decision, with the policy and the reason on it. This is the record for seq 9, the refund that would have exceeded the daily limit:

{"seq": 9, "agent": "demo-agent", "upstream": "stripe",
 "operation": "refund.create", "mode": "active",
 "would": "block", "enforced": "block",
 "policies": ["transaction-limits.approval", "transaction-limits.daily"],
 "reason": "Agent would exceed its $500 daily transaction limit",
 "risks": ["large_transaction", "cumulative_limit"]}

↓ Download the full sample export (.jsonl)

It is data, not a screenshot. Your SIEM can ingest it, and a compliance reviewer can read it without needing access to GrubX.

V. Why this lands with both teams

SREs like it because there is nothing to instrument. There is no agent SDK in every microservice and no redeploy. You point the agent at a GrubX endpoint and the record starts.

Security teams get an audit trail they can hand to a compliance reviewer.

If an agent with write access caused an incident tomorrow, how long would it take you to reconstruct what happened?