AEGIS

AEGIS is a non-custodial policy layer for AI agents that move money. The user brings their own agent, and AEGIS wraps it in a protected wallet — a Safe smart account where that agent is one owner out of three, with a threshold of two. The agent signs, but it cannot execute alone.

Every agent framework tells you to put a private key in an environment variable. None of them can stop the agent from spending it. That is the gap: the key and the rule live in the same place, so anything that reaches the key can move the money — a hallucination, a loop, a prompt injection, or a leaked file. A payment has no undo button.

Users connect their wallet, register the agent they already run, and AEGIS provisions a Hedera account for that agent and deploys a Safe 2-of-3 on Hedera testnet with three owners: the agent signer, the AEGIS co-signer, and a recovery guardian. The user then writes a policy — allowed destinations, allowed tokens, a per-transaction cap, a daily cap, and an expiry. From that point the agent can query chain state and propose an action, but every transaction tool it holds returns unsigned transaction bytes. Broadcasting requires a second signature, and AEGIS adds it only when the action is inside the policy. When it is not, AEGIS does not sign, and without the second signature the transaction cannot exist.

AEGIS never holds the user's key and never holds the user's funds. The Safe belongs to the user, AEGIS is one owner out of three, and its signature alone moves nothing — so a compromised AEGIS cannot drain a protected wallet. AEGIS also never writes or operates the agent, and it does not evaluate why the agent wants to act: judging an agent's stated intent is deliberately out of scope. It enforces the rules the user wrote, and nothing beyond them. The recovery guardian never signs routine transactions. It exists so that a stuck agent signer or a stuck AEGIS co-signer cannot lock a user out of their own wallet.

Built on: Hedera (Hedera SDK, Hedera agent toolkit, HBAR settlement on chain 296), 0G (Agentic ID registration, 0G Compute broker for TEE-backed inference), Safe (protocol-kit, 2-of-3 smart account), LangChain and Groq for the operational agent, Foundry, Next.js, RainbowKit, wagmi and viem, deployed on Hedera testnet.

AEGIS is four components stitched together: a Next.js dashboard, an agent service that owns agent identity and wallet provisioning, a decision verifier built on the 0G Compute broker, and a co-signer service that holds the second signature.

The pipeline: register agent → create a Hedera account via the Hedera SDK → deploy a Safe 2-of-3 on Hedera testnet → register an Agentic ID on 0G → agent proposes an action as unsigned transaction bytes → policy check → AEGIS co-signature → Safe executes → HBAR settles on Hedera.

Hedera is both the execution rail and the identity anchor. When an agent is registered, the agent service creates a real Hedera account for it through the Hedera SDK, and that account becomes the Agent Signer holding a seat on the Safe. The agent runs on the Hedera agent toolkit, so it reads chain state directly instead of through a wrapper, and settlement is a plain HBAR transfer on testnet.

0G covers agent identity and decision verification. Each protected agent gets an Agentic ID registered through a Next.js API route at /api/0g/agentic-id, carrying the owner address, agent name, type, capability list, the agent's Safe address and a policy hash, and returning a token id, a contract address, a metadata URI and an explorer link the dashboard surfaces. The decision verifier is built on the 0G Compute broker, which is what makes a verdict TEE-backed rather than something an ordinary backend asserted.

Safe is the enforcement layer, and it is a real Safe, not a mock vault. createWallet uses @safe-global/protocol-kit with a predictedSafe config, owners set to [agent EVM address, AEGIS co-signer, recovery guardian] and threshold 2. It sends the deployment transaction, waits on the receipt, then reconnects protocol-kit to the resulting address and reads getOwners() and getThreshold() back off the deployed contract rather than trusting the prediction.

The notably hacky part: protocol-kit ships no default deployment for Hedera testnet, so it refuses to predict or deploy a Safe on chain 296 at all — it throws before it ever builds a transaction. We pinned a contractNetworks config for 296 with eight addresses: safeSingleton, safeProxyFactory, multiSend, multiSendCallOnly, fallbackHandler, signMessageLib, createCall and simulateTxAccessor. That block is what lets a standard, unmodified Safe deploy and resolve correctly on Hedera, and it is the single change that made the whole 2-of-3 model possible on this chain.

The second deliberate constraint is on the agent itself. It is a LangChain agent on ChatGroq (llama-3.3-70b-versatile, temperature 0), and every transaction tool in its toolkit returns unsigned transaction bytes and nothing else. The system prompt states plainly that AEGIS decides separately whether to approve and execute. The agent is structurally incapable of broadcasting a transaction, not merely instructed not to.

Honest friction. The co-signer service is still a skeleton that returns 501: it does not yet re-check the policy, verify the receipt signature, or issue Accepted and Denied receipts. The on-chain PolicyRegistry does not exist, so Agentic ID registration currently carries a placeholder policy hash. The subgraph meant to back the audit log is not deployed. And the deeper gap we already know about: the Safe only checks for two of three signatures, so a stolen co-signer key could sign offline without our policy code ever running. Closing that needs a Safe Guard requiring an on-chain 0G attestation before execution, which is blocked on wiring 0G into the co-sign path first.

Proof it runs: Safe 2-of-3 accounts deploy to Hedera testnet as real transactions, and we read owners and threshold back from the deployed contract to confirm the structure. Agentic ID registration returns a live explorer URL per agent.