How I built tamper-proof audit logs for AI agents at 15

Arian Gogani — Wed, 04 Mar 2026 05:27:53 +0000

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?

341 Malicious AI Agent Skills, 1.5M Leaked Tokens — I Built the Fix

Arian Gogani — Mon, 23 Feb 2026 00:58:23 +0000

Three weeks ago, OpenClaw went from zero to 135K GitHub stars. Then it collapsed: 18,000 exposed instances, 341 malicious skills on ClawHub, 1.5 million leaked API tokens, and a one-click RCE exploit that took milliseconds.

The response was predictable — scanners, audits, curated marketplaces. All reactive. All after the damage was done.

I think the real problem is deeper: AI agents get capabilities without ever making verifiable commitments about how they’ll use them.

There’s no protocol for an agent to say “I will not exfiltrate data” in a way that a third party can independently verify. That’s the gap.

Accountability ≠ Observability

Observability tells you what an agent did. That’s a security camera.

Accountability makes agents commit to behavioral constraints before execution. That’s a locked door.

The difference matters. OpenClaw’s skills had full disk access, terminal permissions, and OAuth tokens. Scanning them after installation is like reading the autopsy report. The fix is requiring agents to declare constraints cryptographically before they get access.

What I Built

I built an open protocol called Nobulex where agents publish cryptographically signed behavioral covenants — and anyone can verify compliance independently.

Three lines:

const { protect } = require('@nobulex/sdk');
const agent = await protect({
  name: 'my-agent',
  rules: ['no-data-leak', 'read-only']
});
const result = await agent.verify(); // true

Under the hood:

Ed25519 signatures — the agent’s operator signs behavioral constraints
SHA-256 content addressing — covenants are tamper-proof
Constraint language (CCL) — human-readable rules like deny write on '/external/**'
11 independent verification checks — any third party can verify without trusting the operator

The covenant is immutable once signed. The agent can’t quietly change its constraints. And verification is trustless — you don’t need to trust the operator, the framework, or the platform. You just verify the math.

Why Now

The EU AI Act enforcement begins August 2026. Conformity assessments will demand behavioral documentation and audit trails for AI systems. Not PDFs. Not compliance checklists. Machine-verifiable proofs.

Companies deploying autonomous agents — in finance, healthcare, infrastructure — will need this. The OpenClaw crisis was the preview. Agents will only get more autonomous, manage more resources, and have more access to critical systems.

The question isn’t whether we need accountability infrastructure. It’s whether we build it before or after the next breach.

The Part Nobody Expects

I’m 15. I built this over the past several months — 106,000 lines of TypeScript, 5,053 passing tests, 44 packages, MIT licensed. Every function is real, every test passes, every cryptographic primitive works.

I’m not saying this to impress anyone. I’m saying it because if a teenager can build the infrastructure, there’s no excuse for the industry to not have it yet.

Try It

GitHub: github.com/agbusiness195/NOBULEX

npm install @nobulex/sdk

I want honest feedback. What would make this useful for your agents? What’s missing? What’s wrong?

Drop a comment or open an issue. I’ll respond to everything.