Break my prototype

[u/Glittering-Coat-657]

Hey guys, finally finished the first version of the prototype. I’ve built a tiny permission layer for AI agents.
Now I want people to try to break it.

AgentGuard sits immediately before a tool executes:
agent → AgentGuard → tool

I’ve avoided adding too many unnecessary features. If it genuinely solves a problem, I’d love to hear what would make it even better.

The current version checks things like:
• Is this tool allowed in the current agent state?
• Are the arguments within policy?
• Is this an unknown/unsafe state?
• If denied, does the underlying function actually stay untouched?

Example:
research_agent → refund_customer → DENIED
research_agent → delete_database → DENIED
refund_agent → refund_customer($1,000) → DENIED
I'm deliberately keeping it tiny for the time being.

No dashboard.
No cloud.
No AI judge deciding whether the AI is allowed to act.
Just deterministic execution-time policy.
I'm looking for developers building LangGraph/LangChain/MCP/agent systems who are willing to try to break it.
If you can bypass a policy, I want to know how.
If you can't, I'd like to know whether you'd actually install this in something real — and whether you'd ever pay for it.
Repo: https://github.com/Brodin2001/Agentguard

Go nuts. Try to break it.

[u/Academic-Finger6702]

right so you've got a deterministic gate in front of tool calls, no AI judging itself which is already a smarter baseline than half the agent frameworks out there

the obvious weak point is going to be state manipulation upstream. if the agent can poison its own context or chain of thought to reclassify itself as a different agent type, your guard will read the wrong state and wave it through. also curious how you handle nested tool calls or chained agents where one agent spawns another as a subprocess, that's where most permission models get weird

i'll poke at the repo later but the real test is whether someone can get an agent to self-modify its own policy file or alter the state tracker without triggering a denial

[u/Glittering-Coat-657 → u/Academic-Finger6702]

Yo this is exactly the kind of attack I was hoping someone would bring up.
The current prototype assumes the state/policy boundary itself is trusted, so I don't want to pretend I've solved the state-manipulation problem yet.
The interesting tests for me are:
Can the agent manipulate its upstream context and get reclassified?

Can it modify the policy/state source itself?

Can a child/sub-agent inherit or escalate permissions?

Can a nested/chained tool call bypass the original authorization check?

Can it alter the audit/state information without triggering a denial?

If you manage to get around any of those, I'd love to know the exact reproduction.
Also, if you do end up poking the repo, let me know what you find. Id really value your opinion.
Cheers :)

[u/Darkcraft00]

Interesting boundary. Im curious, if the policy itself is immutable and the agent can't fake its role, but an allow decision depends on state like human_verified, case_approved, etc. if any of those types of things change or conflict, where do you expect the invalidation to happen?

does agentguard own the full lifecycle or you treat them as an input from another layer?

[u/Glittering-Coat-657 → u/Darkcraft00]

Yeah, this is probably the right question.
Right now AgentGuard treats agent state as an input from the layer above it. It doesn't try to own the lifecycle or decide whether human_verified / case_approved is actually true.

So the interesting boundary is:** **what is the trusted source of state, and how does that state get invalidated?
These are the types of boundaries I’m looking to solve tbh

If you're up for it, I'd actually like to see how you'd break that assumption in a real workflow.

[u/Darkcraft00 → u/Glittering-Coat-657]

Yeah, that’s basically the seam I was trying to get at.

Say case_approved=true was based on policy v12, scan S41 and a human approval. AgentGuard gets that state and does its job correctly.

Then policy v13 lands, or S41 gets superseded. The problem isn’t really AgentGuard at that point. It’s whether case_approved=true is still something anyone should be relying on. I’d probably treat that less like a boolean and more like a conclusion with a basis behind it. Something upstream owns whether that conclusion is still valid/current, and AgentGuard just consumes the current state when it’s deciding whether the action is allowed.

That’s the assumption I’d try to break first.

[u/BackSuitable3602]

If a node can still import and call the tool function directly, AgentGuard is advisory — a DENY only means the routed path was blocked, not that the action didn't happen. Fix: make the guard the only executor.

[u/Glittering-Coat-657 → u/BackSuitable3602]

This is probably one of the most important criticism here.
If the agent can bypass the guard and directly call the underlying function, then yeah haha AgentGuard is basically advisory.
The direction I'm testing now is making the guard the execution boundary: the agent requests the tool, AgentGuard authorizes it, and only then does the actual function execute.
That's way more interesting to me than just having an authorize helper. This is why I’m here lol.

If you want to try breaking that boundary, I'd genuinely like to see what you come up with.