Phinq is an open source runtime governance layer for AI agents. It intercepts every agent tool call, classifies it by risk, lets safe actions pass, holds irreversible actions for human approval, and records each decision in a tamper-evident hash-chained audit log.
I built Phinq because I watched an agent overwrite something it shouldn't have touched.
I'm 21, a fresh graduate in London, and after graduating I couldn't find a job. So I went deep on the AI builder side. Tinkering. Learning. Trying to find my way in.
Everyone was racing to make agents smarter. Then I watched an agent overwrite something it had no business touching, and it clicked. Nobody was asking the harder question. What should agents actually be allowed to do?
This isn't hypothetical. In April, a coding agent deleted a company's entire production database and all its backups in nine seconds. Another wiped 1,206 executives' records during a freeze its user had explicitly declared. These are already happening to real teams.
Phinq is the answer. An open source layer that sits between an agent and the world. Before an action happens, it decides how risky it is. Reversible things pass through. Irreversible things pause and ping your phone. It checks the action against the rules you set, then writes a tamper-evident audit log of everything.
On our own stats page: 9,031 decisions classified, 323 held, 50 denied, 116 safeguard-disable attempts. And counting.
Agents don't need more power. They need a bouncer.
And the clock is running. The EU AI Act started enforcing human oversight 10 days ago. This isn't the nice-to-have layer anymore. It's becoming the required one.
It's open source (MIT), and it works with OpenAI, Anthropic, LangChain, CrewAI, AutoGen, and anything that speaks those APIs. Either a governance proxy, or a lightweight skill you drop straight into Claude Code, Codex, and OpenCode.
I couldn't find a job, so I built one. In public.
If you think agents need guardrails, the upvote means a lot. Happy to answer anything in the comments.
Report
"Nobody was asking the harder question: what should agents actually be allowed to do" is a better problem statement than most funded companies in this space have written down.
Classify by risk is the load-bearing step and it is where the pressure will land. delete_file is not a risk level, it is a verb. The same call is trivial on a temp artefact and unrecoverable on the only copy of something, and that difference lives in the argument and in the state of the world. Neither is carried by the tool name. So the classifier ends up guessing reversibility without knowing what is being acted on.
Can a Phinq rule read the arguments, or does it decide on the signature? And can an operator declare "this path is precious" so the answer comes from a human rather than a model?
@rabnoor_s this is the right question and I’m glad you asked.
delete_file on a temp cache and delete_file on the only production backup are not the same risk. but the classifier sees the same verb.
right now phinq goes by tool name first. a named delete tool gets flagged irreversible before anything else. it's the cautious default.
shell surfaces are different. raw rm -rf / and DROP TABLE through bash do get argument inspection. but that path is conservative right now. it flags but mostly allows. sql through a shell is harder to classify correctly than a named tool.
the thing you're asking about. declaring "this path is precious" doesn't exist in the proxy yet. it's the obvious direction. phinq learn is the vector. once it's seen you deny rm on /home/prod but allow it on /tmp/build, it starts inferring the boundary.
you're pointing at the hard part. "classify by risk" only works if the classifier sees more than the verb. state of the argument and state of the world are where the actual risk lives.
what would a 'precious path' rule look like in a config file that you'd trust?
Report
The idea of holding irreversible actions for human approval is really smart, adds a layer of safety to AI agent interactions.
That's the whole point of phinq. Agents should be able to do the work without the risk. No one wants to wake up to everything deleted or an overboard credit bill, especially as LLMs get smarter and do their own thing.
For you personally, what would you never let an agent touch unsupervised?
Phinq
"Nobody was asking the harder question: what should agents actually be allowed to do" is a better problem statement than most funded companies in this space have written down.
Classify by risk is the load-bearing step and it is where the pressure will land. delete_file is not a risk level, it is a verb. The same call is trivial on a temp artefact and unrecoverable on the only copy of something, and that difference lives in the argument and in the state of the world. Neither is carried by the tool name. So the classifier ends up guessing reversibility without knowing what is being acted on.
Can a Phinq rule read the arguments, or does it decide on the signature? And can an operator declare "this path is precious" so the answer comes from a human rather than a model?
Phinq
@rabnoor_s this is the right question and I’m glad you asked.
delete_file on a temp cache and delete_file on the only production backup are not the same risk. but the classifier sees the same verb.
right now phinq goes by tool name first. a named delete tool gets flagged irreversible before anything else. it's the cautious default.
shell surfaces are different. raw rm -rf / and DROP TABLE through bash do get argument inspection. but that path is conservative right now. it flags but mostly allows. sql through a shell is harder to classify correctly than a named tool.
the thing you're asking about. declaring "this path is precious" doesn't exist in the proxy yet. it's the obvious direction. phinq learn is the vector. once it's seen you deny rm on /home/prod but allow it on /tmp/build, it starts inferring the boundary.
you're pointing at the hard part. "classify by risk" only works if the classifier sees more than the verb. state of the argument and state of the world are where the actual risk lives.
what would a 'precious path' rule look like in a config file that you'd trust?
The idea of holding irreversible actions for human approval is really smart, adds a layer of safety to AI agent interactions.
Phinq
@aymnart Appreciate that, means a lot.
That's the whole point of phinq. Agents should be able to do the work without the risk. No one wants to wake up to everything deleted or an overboard credit bill, especially as LLMs get smarter and do their own thing.
For you personally, what would you never let an agent touch unsupervised?