Software makes promises it can't prove it kept.
"I won't transfer more than $500." "I'll only access these three APIs." "I won't touch production data." Every AI agent makes commitments like these. But when something goes wrong, all you have are logs — logs that the software itself wrote. That's like asking a suspect to write their own police report.
I'm 15, and I spent the last few months building Nobulex to fix this.
The problem
AI agents are moving from demos to production. They're handling money, making procurement decisions, managing infrastructure. But there's no standard way to:
Define what an agent is allowed to do
Enforce those rules at runtime
Prove — cryptographically — that the agent followed them
Existing solutions are either post-hoc monitoring (you find out after the damage) or prompt-level guardrails (which can be bypassed). Nothing sits at the action layer with tamper-proof logging.
What I built
Nobulex is open-source middleware with three components:
A rule language. Cedar-inspired, dead simple:
permit read;
forbid transfer where amount > 500;
require log_all;
Runtime enforcement. Every agent action passes through the middleware. If it violates a rule, it gets blocked before execution. Not logged and reported — blocked.
Tamper-proof audit trail. Every action (allowed or blocked) gets recorded in a hash-chained log. Each entry includes the action, the rule that matched, a timestamp, and a cryptographic hash linking it to the previous entry. Anyone can independently verify the entire chain. If a single entry is altered, the chain breaks.
The 3-line integration
javascriptconst { protect } = require('@nobulex/quickstart');
const agent = protect('permit read; forbid transfer where amount > 500; require log_all;');
const result = agent.check({ action: 'transfer', amount: 200 });
// result.allowed === true
That's it. One import, one setup, one check.
Why hash chains matter
A traditional log is a text file. Anyone with access can edit it. A hash-chained log works differently — each entry's hash is computed from its content plus the previous entry's hash. Change one entry and every hash after it becomes invalid. It's the same principle behind blockchains, but without the overhead.
This means a third party can take your audit log, recompute every hash from the first entry, and mathematically verify that nothing was tampered with. No trust required.
The hard part
Building the cryptography and middleware was straightforward. The hard part was designing the rule language.
My first version was too complex — it had nested conditions, boolean logic, inheritance hierarchies. Nobody wanted to write rules in it. I scrapped it and started over with three keywords: permit, forbid, require. If you can't express your rule with those three words, the rule is too complex.
The where clause handles conditions: forbid transfer where amount > 500. That's readable by someone who's never seen the DSL before. That was the goal.
What's next
The project has 6,100+ tests across 61 npm packages. It's MIT licensed and works today.
What I'm working on:
Framework integrations — LangChain works now, CrewAI and MCP are next
A hosted version — managed compliance infrastructure so you don't have to self-host the verification
Certification badges — "Nobulex Verified" for agents that pass continuous compliance checks
Try it
Live demo: nobulex.com
GitHub: github.com/nobulexdev/nobulex
npm: npm install @nobulex/quickstart
I'd love feedback on the rule language. Is permit/forbid/require intuitive? Would you design it differently?
Top comments (0)