the firewall that sits in front of production.
agent.shield is a transparent http proxy with a policy engine and a human approval queue. your agent calls a url; we decide, by your rules, whether it runs now, waits for a human, or never happens. here's exactly how it works.
the request lifecycle.
every call your agent makes flows through four stages. safe traffic doesn't slow down. dangerous traffic doesn't get through.
01
intercept
your agent calls the proxy url. agent.shield captures the method, path, headers, query, and body. it doesn't modify them.
02
evaluate
the policy engine runs your rules against the request. a match means destructive; no match means safe.
03
decide
safe requests are forwarded instantly. destructive ones are held and pushed to the review queue for a human.
04
forward or block
on approve, we replay the original request to your real target and return the response. on deny, it never runs.
rules that match the way damage happens.
a policy is a small json rule: a method (or *), a path_regex, and an optional body_regex. any request that matches a rule is treated as destructive and held. it's deliberately simple. no new dsl to learn, just the patterns you already recognize.
- match on http verb — hold every DELETE, or only DELETE on /customers/*.
- match on payload — catch drop table, truncate, delete from, rm -rf, kubectl delete.
- ship with safe defaults, then tune per proxy as you learn your agents.
[
{ "method": "DELETE", "path_regex": ".*",
"label": "http delete" },
{ "method": "*", "path_regex": ".*",
"body_regex": "drop\\s+table",
"label": "drop table" },
{ "method": "*", "path_regex": "/k8s/.*",
"body_regex": "kubectl\\s+delete",
"label": "kubectl delete" }
]DELETE /v1/customers/8821
pendingheld — destructive action awaiting your decision
matched policy “http delete”
host: api.internal.acme.com
authorization: bearer ••••••••
{ "cascade": true }
the moment a human decides.
when a request is held, the agent receives a 202 with a pending status and a review link, so it knows to wait instead of failing blind. the action lands in your queue with everything you need to judge it.
- inspect the full request: method, path, headers, and body.
- see which policy it matched and where it's headed.
- approve to replay it for real, or deny to block it — one click.
one url. that's the whole integration.
no sdk, no sidecar, no agent rewrite. create a proxy in settings, copy the generated url, and point your agent's base endpoint at it. agent.shield forwards to your real target on the other side.
# before — agent calls prod directly
curl -X DELETE \
https://api.acme.com/v1/customers/8821
# after — agent calls agent.shield
curl -X DELETE \
https://agent.shield/api/proxy/<token>/v1/customers/8821
# → 202 held_for_review
# { "request_id": "...",
# "review_url": ".../requests/..." }the queue follows you.
pending actions are time-sensitive. the dashboard gives the full picture on desktop; the same review fits in your pocket so an agent never stalls waiting on someone at a laptop.
dashboard
pending
3
approved
128
denied
14
intercepted
1.4k
pending approvals
DELETE /v1/customers/8821
prod database agent · drop record
POST /query
prod database agent · drop table
DELETE /k8s/pods/web-7f
prod database agent · kubectl delete
agent.shield
1 action needs you
DELETE /customers/8821
prod database agent
ship agents without holding your breath.
give your agents production access — and give yourself the final say.