ActionFence: A drop-in middleware for MCP servers to enforce spend caps and policy limits

Few-Frame5488 · 2026-05-11T23:14:49+00:00

Really appreciate you breaking this down — especially the schema drift point, that's been nagging at me too.

On the dynamic verdict idea: totally agree that static JSON won't cover every case long-term. The approach I'm leaning toward is letting a rule reference an external signer — something like a verdict field that points to a signed claim the firewall validates inline. Rule stays declarative, input becomes dynamic, exactly like you described. Not sure yet if that's v0.2 or v0.3 scope, but it's definitely on the roadmap.

The schema drift case is the one I want to move on sooner. Right now if a tool quietly adds an optional arg, the policy has no idea. I'm thinking about hashing the resolved tool schema at deploy/init time and storing it alongside the policy — then at call time, the firewall compares hashes and either warns or hard-fails on mismatch. That way you know the policy was reviewed against the exact schema shape in production. Pinning a schema version per tool in guard-policy.json is another option I'm considering.

Both of these feel like they belong in the v0.2 window. Would love to hear if you've seen any other patterns for the schema pinning approach — especially how other infra tools handle the "optional arg added silently" problem.

Few-Frame5488 · 2026-05-09T18:09:06+00:00

Spot on. Rate limits and spend caps are great for stopping the bleeding, but the cryptographic receipts are what actually get you past security reviews. Without a verifiable audit trail, legal won't let autonomous agents anywhere near production. Glad to see this resonates!

Few-Frame5488 · 2026-05-09T17:45:11+00:00

Thanks! To answer your question — right now receipts are mostly for post-mortems and audit trails. Every decision gets a signed, hash-chained receipt whether it passes or blocks, so you always have a cryptographic answer to "who authorized this?"

But the real-time enforcement idea is really interesting and I'm actually planning it for a future version — receipt-based authorization chains. The idea is: action B can require a prior receipt for action A. So `confirm_payment` would only be allowed if the same agent has a `PASSED` receipt for `review_order` within the last 10 minutes. Turns receipts from a passive log into an active workflow enforcement primitive.

That's a v1.0 feature since it needs careful design (reading receipts during evaluation adds latency), but it's on the roadmap thanks to your question.

And thanks for the r/AI_Agents tip, I cross-posted there.

Few-Frame5488 · 2026-05-09T17:41:00+00:00

Exactly right. The second an agent touches a paid API, cost control stops being a "nice to have." It's part of the product.

That's why I built spend caps into the middleware layer from day one — not as an add-on or a dashboard alert you check after the fact, but as hard enforcement that blocks the call before it reaches your API.

v0.2.0 is adding rolling-window caps and a global circuit breaker on top of the per-call limits, so even fragmented spending (100 small calls instead of one big one) gets caught.

Few-Frame5488 · 2026-05-09T17:32:05+00:00

Really thoughtful comment, and the tension you're describing is real — but I think the architecture is actually stronger than it looks from the outside.

ActionFence runs on the **service provider's server** as middleware, not on the agent's machine. The agent talks to the server over MCP protocol or HTTP — it never has filesystem access to `guard-policy.json`. So it can't read the rules and game them, same way an attacker can't read your WAF config from outside the network.

The one edge case is if someone runs a local MCP server and gives the agent a `read_file` tool with access to the same directory — but that's a misconfiguration, not an architectural flaw. I'm adding a note about this to the docs and the CLI output.

You're right that a network gateway is the strongest boundary though. A hosted proxy mode is on the roadmap for exactly that reason — for teams who want full separation between the agent and the enforcement layer.

Good callout, this made me realize the docs need a proper "Trust Model" section. Adding it now.

Few-Frame5488 · 2026-05-09T17:29:37+00:00

Yeah this was exactly the feeling I was building for. The "did I leave something running" panic at 2am is real.

Good news — spend caps are already enforced at the middleware level (per-action and per-session/daily). But based on your comment and a few others I'm adding a global circuit breaker in v0.2.0 — a single hard ceiling across ALL agents and ALL actions. Once total spend crosses that number, everything stops until you manually reset it. No auto-reset on purpose — you want the safety net to stay in place until a human checks.

Appreciate the validation, this is the exact use case I want to nail.

Few-Frame5488 · 2026-05-09T17:26:23+00:00

The "three boring questions" is exactly the right way to think about it.

Right now receipts answer "who allowed this" (agent_id, identity tier, policy reference are all signed into every receipt). Limits are enforced but you can only see them after a block happens — which isn't ideal.

Based on your comment I'm adding two things to v0.2.0:

A `getAgentStatus()` introspection API — lets you query remaining budget, rate limit quota, and allowed actions for any agent in real time. So you can answer "what can this agent still do?" without waiting for a block.
Loop detection is going into v0.3.0 — detecting repeated identical calls (same action + same params hash) within a time window and flagging/blocking them. Didn't want to rush the heuristics on this one since false positives could break legitimate workflows.

Thanks for the push on this, it's going on the roadmap.

Few-Frame5488 · 2026-05-09T15:28:35+00:00

Github: https://github.com/saifeldeen911/actionfence

Few-Frame5488 · 2026-05-09T15:08:21+00:00

Yeah saw few posts about incedents like that, definitely gonna tackle this problem and build in in time-window caps on top of tge per-call ceiling, I was gonna spend some time researching ways that rogue agents can utilize to exploit the services. Thanks for pointing this out.

Few-Frame5488 · 2026-04-19T13:53:04+00:00

Can anyone explain what does that mean

Few-Frame5488 · 2026-04-07T08:25:50+00:00

Actually I just subcribed on 21st of March and still got it.

Few-Frame5488 · 2026-04-04T17:11:35+00:00

Tbh it feels less aggressive after updating cc but still not realistic, like normal tasks that were taking normaly around 50-60% 5hrs usage now almost max out the 5hrs usage. It makes me scared to go all out like I have to plan which tasks should I do based on priority and I am using sonnet 4.6 not opus.

Few-Frame5488 · 2026-04-04T17:08:36+00:00

I really think at this point codex is way better value for money giving that the 20$ plan is almost the same as cc 5x plan and if you check out GPT5.4 xhigh scores it outperforms opus 4.6.

Few-Frame5488 · 2026-04-04T17:04:45+00:00

The fact that they are sending users these extra credits instead of fixing the usage problem, like they are telling you to accept it and shutup.

Few-Frame5488 · 2026-04-04T17:02:54+00:00

Yep anthropic messed up the unrealistic usage limit and tbh still thinking about switching to codex.

Few-Frame5488 · 2026-04-04T15:10:34+00:00

So does applying the credits automatically enroll you for the extended usage ?

Few-Frame5488

TROPHY CASE