In April 2026, a team using PocketOS watched Claude Opus 4.6 — running via Cursor — delete their entire production database and every backup in und...
For further actions, you may consider blocking this person and/or reporting abuse
The structural gap you describe is real. Nothing
between the LLM and the tools it can call. The
gateway approach fixes it for single-agent setups
where you control both sides.
The problem I keep thinking about is what happens
when agents interact with each other across trust
boundaries. A gateway can scope one agent's access
to your tools. But when agent A buys a signal from
agent B, who enforces that B had the capability to
produce that signal? Who enforces that A had the
funds to pay? Who slashes B's stake if the signal
was fraudulent?
That is the layer I am building. An L1 blockchain
where AI entities have protocol-enforced capabilities,
on-chain reputation, staking with slashing, and
cryptographic proof verification. The chain rejects
transactions that exceed an entity's permissions
before execution. Not a gateway in front of the
agent, but infrastructure underneath all agents.
Your gateway solves the single-org problem well. The
multi-agent, cross-trust-boundary problem needs
something at the protocol layer. Both are needed.
The layer distinction is real and worth naming clearly. What I'm building is governance infrastructure for teams deploying AI agents inside their own trust boundary — where the org controls both the tools and the agents calling them. The problem there is audit, scope enforcement, and operational reliability. No cross-entity trust required.
What you're describing is the coordination layer for agents operating across trust boundaries — strangers transacting, no shared org to enforce the rules. That genuinely needs something at the protocol layer. A gateway won't get you there.
Two different problems. Two different deployment contexts. The enterprise compliance buyer isn't on an L1 yet — they want a Docker command and an audit trail. The multi-agent economy buyer doesn't exist at scale yet, but the infrastructure has to be ready before the agents arrive.
What chain are you building on / starting from scratch?
From scratch. Rust, HotStuff BFT consensus,
custom state machine. 104K lines, 1,768 tests,
16 crates. github.com/0x-devc/NOVAI-node
The reasoning: agent identity, reputation,
capability enforcement, and payment settlement
need to be in the state transition function, not
in contracts layered above it. Existing chains
treat an agent as an address. NOVAI treats it as
a first-class account type with its own key,
nonce, capabilities, reputation score, and stake.
You are right that these are two different
deployment contexts. The enterprise compliance
buyer wants a Docker command and an audit trail.
The multi-agent economy buyer needs protocol-level
coordination. Both are real markets but the
infrastructure for the second one has to exist
before the agents arrive in volume. That is the
bet.
HotStuff BFT in Rust from scratch is a serious bet. Respect for building at that layer instead of just wrapping an existing chain.
The "agent as address" vs "agent as account type" distinction is the crux. What I keep running into on the enterprise deployment side is that identity and capability enforcement are already urgent problems — they're just being solved badly, by hand, at the gateway layer because no protocol primitive exists yet.
Right now, if I want to answer "Which agent made this call, under what capability scope, with what context?" I'm encoding that in audit logs and gateway middleware. It works for the compliance buyer because centralized trust is sufficient — an immutable log satisfies their auditor. But it doesn't compose across organizations or survive a Byzantine actor.
What you're building is what happens when centralized trust stops being sufficient and the volume of agent-to-agent coordination exceeds what any single gateway can referee. The patterns are the same — identity, capability scoping, reputation, settlement — but the trust model is different.
Your framing that "the infrastructure has to exist before the agents arrive in volume" is the honest version of the thesis most people in this space won't say out loud. The enterprise buyer needs the Docker command today. The multi-agent economy buyer needs your state transition function before they even know they exist.
Both true. Different clocks.
The "two clocks" framing is sharper than I had it. The enterprise gateway pattern you're describing is exactly the bridge layer I keep telling people NOVAI is not trying to replace. Centralized identity + audit logs + middleware-enforced capability scoping is the right architecture for the single-org compliance buyer. The friction starts when those gateways have to talk to each other across trust boundaries that don't exist yet.
What I keep finding in the protocol design is that a lot of what the gateway layer does by hand is actually shaped like a state transition. "Which agent made this call, under what capability scope, with what context" that's a four-tuple. On NOVAI it's literally a four-tuple: entity_id, capability bits at signal-handler time, the call's signal type, the block height it landed in. The audit log is the chain. The compliance buyer who currently trusts the gateway-emitted log gets the same artifact, just with the trust assumption swapped from "we promise we wrote this correctly" to "any validator can verify the same record."
The bit I'm still working out is the migration path. The compliance buyer's auditor doesn't care that the log is on a public chain, they care about chain-of-custody for their data. So the question is whether the chain becomes a backstop attestation layer underneath the existing gateways (gateway emits, chain anchors the hash, auditor verifies both), or whether multi-org coordination forces a clean break to chain-native identity. Probably both, depending on the buyer.
The clock thing is going to be the marketing problem more than the engineering problem. The audience that needs this in 2026 isn't the audience that's deploying agents today.
The four-tuple framing just recontextualized something I've been building by feel. Every audit entry I write has exactly those four fields — I just didn't have a name for the shape. entity_id, capability scope at call time, operation type, timestamp. The difference is that my timestamp is a wall clock in a log file, and yours is a block height with validator consensus behind it. Same structure, different trust provenance.
On the migration path: from what I've seen on the enterprise deployment side, the attestation layer model is probably where it starts. The compliance buyer's auditor doesn't care about decentralization — they care about tamper-evidence and chain-of-custody. A gateway that emits structured logs and anchors hashes to a public chain gives them both without asking them to change their mental model of what an audit log is. The clean break to chain-native identity only becomes worth the switching cost when cross-org coordination is actually happening at volume, which means the enterprise buyer won't push for it — the aggregator sitting between enterprises will.
Your last line is the honest version of every infrastructure timing problem. I'd add one edge: the audience deploying agents today doesn't know they need your state transition function yet because their failure modes are still small enough to debug manually. The moment multi-agent coordination exceeds what a single person can trace in a log file, the demand materializes quickly. The marketing problem isn't convincing people the clock exists — it's being positioned when the alarm goes off.
In the old school way, will a senior developer or team lead, let the new super smart junior developer do everything, without being monitored and supervised? Will somebody give this highly confident soul, without any, experience the privileges to do any kind of deletion?!
Having agents to work for you is a responsibility, and not a reason to get lazy ;)
Exactly the right analogy — and exactly the problem most teams skip until something breaks.
The "brilliant junior dev with root access" is a perfect way to frame what most MCP deployments look like today. The tools are capable. The agents are confident. Nobody installed the guardrails.
A senior dev doesn't just hire the junior — they define what they can touch, log what they did, and review before anything irreversible runs. That's the governance layer MCP is missing by default.
Agents working for you should feel like a well-managed team, not a contractor with your SSH key and no Slack. The responsibility doesn't go away because the worker is an AI. If anything, it scales faster.