the wedge: proxy + approval

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 is exactly how it works.

the request lifecycle.

every call your agent makes flows through four stages. safe traffic never slows down; dangerous traffic never slips through.

01

intercept

your agent calls the proxy url. agent.shield captures the method, path, headers, query, and body — without modifying 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.

policy engine

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 is 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.
policies_json
[
  { "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" }
]
agent.shield/requests/8821
agent.shield
sre@acme.com

DELETE /v1/customers/8821

pending

held — destructive action awaiting your decision

matched policy “http delete”

DELETE /v1/customers/8821
host: api.internal.acme.com
authorization: bearer ••••••••
{ "cascade": true }
denyapprove & forward
approval workflow

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. meanwhile the action shows up 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 would be sent.
  • approve to replay it for real, or deny to block it — one click.
integration

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.

1create a proxy → get a unique url + token
2swap your agent's base url for the proxy url
3watch requests land in your dashboard, live
before → after
# 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/..." }
review anywhere

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.

agent.shield/dashboard
agent.shield
sre@acme.com

dashboard

pending

3

approved

128

denied

14

intercepted

1.4k

pending approvals

DELETE /v1/customers/8821

prod database agent · drop record

pending

POST /query

prod database agent · drop table

pending

DELETE /k8s/pods/web-7f

prod database agent · kubectl delete

pending

agent.shield

1 action needs you

pending

DELETE /customers/8821

prod database agent

denyapprove

ship agents without holding your breath.

give your agents production access — and give yourself the final say.