Building AI Agents Right — Foris / Crypto.com

⬡ Reference Architecture · May 2026

Building AI Agents
Right.

A Reference Architecture

Neet (Clement Wong)
Director, Solutions Engineering COE, APAC — Cloudflare
Presented to Foris / Crypto.com · May 2026

Act 1 — The Shared Bet · 0:30–2:30

You bought ai.com.
That's a platform bet.

Your bet — Foris / ai.com

Spent $70M because the agentic future is a category, not a feature
Launched at the Super Bowl — ai.com as big as crypto.com
Building onchain — agents owned by users, not platforms

My bet — OpenClaw

Same thesis. Different stack.
138,000 GitHub stars · 1M+ weekly downloads
Built on Cloudflare. Open-source. Production.

Let me show you the architecture I landed on — and the decisions you'll need to make building yours.

Act 2 — Reference Architecture · 2:30–4:00

OpenClaw on Cloudflare —
The Three Layers

👁️

Layer 3 — Observe Everything

Full audit trail · Session replay · Anomaly detection · "If you can't see it, you can't trust it."

🔒

Layer 2 — Scope Permissions

Tool registry · Sandboxed execution · Human-in-the-loop for high-stakes actions

🔑

Layer 1 — Connect Securely

Per-agent identity · JIT credentials · Mutual TLS · Zero Trust network egress

Cloudflare AI Gateway Workers Zero Trust KV / R2 / Durable Objects

Framework: Volker Rath (Cloudflare) — Connect · Scope · Observe

Layer 1 — Connect Securely · 4:00–5:30

The question isn't who the user is.
It's who the agent is.

❌ The Default (most platforms)

Shared service account for all agents
Static API keys that never rotate
No per-agent audit trail
One compromised agent = all agents compromised

✓ The OpenClaw Approach

Unique credentials per agent — issued at task time, revoked after
JIT access — no standing permissions anywhere
Mutual TLS — both sides authenticate
Zero Trust egress — tunnels, not open gateways

Your agents should never have more access than a junior employee on their first day.

"Let's start with the most fundamental question: how does an agent prove who it is? In most AI platforms, the answer is 'it doesn't.' Agents share a service account. One token, all agents use it. It's convenient. But if any agent gets compromised — through prompt injection, a malicious skill, whatever — the attacker now has every agent's power. We went the opposite direction. Every agent in OpenClaw has its own cryptographic identity. When a task starts, the agent requests access. Credentials are issued with a time limit, scoped to exactly what that task needs. When the task completes, they're revoked. For a regulated crypto exchange launching an AI platform, this isn't optional. If any of your agents ever touches financial data, you need to know EXACTLY which agent did what — and you need to be able to cut off a compromised agent without shutting down the whole platform."

Layer 1 — Connect Securely · 5:30–6:30

How OpenClaw Connects —
The Flow

Task
Assigned
Intent

2
Agent Requests
Credentials
JIT Token ⏱

Connects
to Tool
mTLS

Tool Validates
Identity
Scoped only

Task
Completes
Auto-revoke 🗑

Audit Record
Created
Immutable log

⚠️ If you're building your platform: This is the first thing to wire in — before you hit 100 agents. The cost of adding per-agent identity later is exponentially higher than building it now.

Layer 2 — Scope Permissions · 6:30–9:00

Agents should be powerful.
Not omnipotent.

If an agent can call any tool, it will eventually call the wrong one — through prompt injection, hallucination, or user error. The model can't enforce scope. Only infrastructure can.

①

Tool Registry

Every callable tool must be explicitly registered. Unregistered = unreachable. The tool simply doesn't exist to the agent.

②

Sandboxed Execution

Every tool runs in isolated Workers with explicit data bindings. The sandbox IS the permission model — not a wrapper around it.

③

Human-in-the-Loop

For anything irreversible — sending funds, publishing, modifying accounts — the agent queues the action. A human approves. Only then does it execute.

🏦 For Foris: HITL for all financial-agent interactions needs to be in your v1 spec. Not v2. V1.

"This is the layer most platforms get wrong. Not because they're careless — because the default behavior of LLMs is 'give the model everything and let it figure out what to use.' That's great for demos. It's dangerous for production. We use three mechanisms. Tool registry — an explicit allowlist of what each agent can call. Sandboxed execution — every tool runs in Workers with explicit bindings, so even if an agent tries to access something, it physically can't reach it if it's not in the bindings list. And for you specifically — human-in-the-loop gates. If your AI agent platform can touch any financial workflow, the ability for a HUMAN to stop an agent action before it executes is not a feature. It's the entire trust model. Build it in v1."

Layer 3 — Observe Everything · 9:00–11:00

If you can't see it,
you can't trust it.

What OpenClaw Observes

Every prompt sent — what the agent asked, what context was included
Every response received — what the model said, token count, latency, cost
Every tool call — which tool, what params, response, duration
Rate anomalies — if an agent makes 10× normal calls, we catch it
Full session replay — reconstruct any agent session exactly

📋 Audit Entry Example

                agent: finance-bot-7

                tool: send_payment

                params: amount=500 USDC

                status: HITL_APPROVED

                approver: user:clement

                ts: 2026-05-14T10:42:01Z

⚠️ Anomaly Alert

Agent finance-bot-3 — 15× normal API call rate detected. Auto-throttled.

If a regulator asks "what did this agent access and why?" — your answer should be a log entry, not a discussion.

"The third layer is the one that MAS cares about most. We log everything in OpenClaw. Every prompt. Every response. Every tool call. Every credential issued. And we have full replay — I can reconstruct any agent session from start to finish. Why does this matter for you? Because when MAS comes asking — and they will, given their recent AI governance framework specifically calls out agentic AI — you need to answer with a log, not a discussion. There's a specific requirement in the new guidelines being published: auditability of AI system actions. Your platform needs to be built on an infrastructure that provides immutable, queryable audit trails. The other reason: debugging. When an agent does something unexpected, replay lets you see exactly what the model received and what it responded with. You can't fix what you can't reproduce."

Act 3 — The Foris Equation · 11:00–14:00

What changes when
you're Foris?

① Regulatory Stack

MAS DTSP + Agentic AI Governance

Dual compliance. Most AI platforms don't face this. Yours does.

MAS specifically mandates: scope, audit, lifecycle, data segregation for all agentic AI.

Active enforcement

② Asset Exposure

Data vs. Assets

Non-financial AI compromised → data exfiltration

Foris agent compromised → asset movement.

Different class of problem. Entirely.

③ Ecosystem Context

The $CLAWD Signal

$16M market cap fake token — same playbook that will target YOUR platform.

You've been here before — 2022 breach. You know what sophisticated attackers look like.

You're not just building an AI platform. You're building a financial AI platform. Different requirements. Higher stakes. And better positioned to get it right because you already understand the threat model.

[Slower here. This is the empathy section. You've done your homework and they should feel it.] "Let me talk specifically about your situation, because it's not the same as most AI platform builders. First, regulation. You're MAS-regulated as a DTSP. Now you're adding an AI agent platform that falls under MAS's new Agentic AI Governance Framework. That's a dual regulatory stack that most AI companies don't have to worry about. But you do. The good news: the things MAS is asking for — identity, auditability, scope control, data segregation — are exactly the architecture decisions I've been describing. They're not separate from your product design. They ARE your product design. Second, asset exposure. This is the one that keeps me up. If a non-financial AI agent is compromised, it's data exfiltration. Bad. If a Foris agent is compromised, it's asset movement. Different class of problem entirely. Your architecture needs HITL gates for any financial transaction, period. Third — you've been through this before. The 2022 breach. You know what sophisticated attackers look like. And with the $CLAWD token hitting $16M on Solana through an AI agent exploit — that's exactly the playbook that'll target your platform. You can see it coming because you already understand this world."

Landscape · 14:00–15:00

The AI Agent Landscape —
Where You Fit

General AI Agents

OpenClaw Open-source · 138K stars · Cloudflare-native

OpenAI Agents Enterprise · Closed

Lindy / LangFlow Workflow automation

Crypto-Native AI Agents

Virtuals Protocol Base network · Agent economy

ElizaOS Open-source crypto agent framework

CLANKER Emerging protocol

ai.com — Your Position

              Consumer-product-first
              Not token/protocol-first
            
              Onchain by design
              Users own their agents
            
              Edge-powered for scale
              Cloudflare = complement, not compete

Cloudflare at the edge is complementary to your onchain architecture — not competing with it. You handle decentralized logic. We handle global delivery, security, and distribution.

Ecosystem Data · 15:00–16:00

What the Ecosystem
Is Teaching Us

OpenClaw's growth has been explosive — and the security issues scaled just as fast.

42,900

Exposed agent instances — public internet, no auth, 82 countries

15,200+

With RCE vulnerabilities — pre-built attack vectors

341+

Malicious skills on ClawHub — supply chain poisoning is real

CVE-2026-25253

Auth token theft → Full RCE. One vuln, all agents.

$CLAWD

$16M market cap fake token on Solana — rug pull via AI hype. In your world.

Every exploit in the OpenClaw ecosystem is a preview of what targets YOUR platform. You now know what the industry learned the hard way. Use that.

Act 4 — Platform Requirements · 16:00–18:00

9 Guardrails →
Product Requirements

⬡ Layer 1 — Connect

①

Unique credentials per agent
Non-negotiable

②

JIT access — no standing permissions
Design principle

③

mTLS between agents and tools
Defense in depth

⬡ Layer 2 — Scope

④

Tool registry — explicit allowlist
Unregistered = unreachable

⑤

Sandboxed execution
Isolation by design, not wrapper

⑥

HITL gates for financial actions
v1 requirement. Not v2.

⬡ Layer 3 — Observe

⑦

Full audit logging
Immutable · queryable · replayable

⑧

Rate limiting + anomaly detection
Per-agent, not aggregate

⑨

Skill supply chain governance
Who can publish? What vetting?

These aren't security controls bolted onto a product. They're product features your platform can't ship without.

Starting Points · 18:00–19:00

If I were starting
your platform today

Three things to wire in before you ship anything externally:

①

Agent Identity Model

Build per-agent identity into your protocol layer. Not optional. Every agent gets its own cryptographic identity. Affects your credential model, audit trail, and trust architecture. Hard — and expensive — to add later.

Build this first

②

Audit Trail Architecture

Define your audit schema before you write your first agent handler. What gets logged? How stored? How queried? Make it immutable and replayable from day one. Your future regulator will thank you.

Before your first MAS query

③

Human-in-the-Loop for Financial Actions

HITL in the protocol, not the UI. The agent literally cannot execute a financial transaction without human approval. This is your regulatory requirement AND your user trust model.

Before your first incident

"If I were building what you're building — starting from scratch — here's where I'd begin. Number one: agent identity. Build it into your protocol layer. Every agent gets its own cryptographic identity. This affects everything downstream — audit, scope, revocation. And it's exponentially harder to add after you've shipped. Number two: audit trail architecture. Define your schema before you write your first handler. Know what you're logging, how it's stored, how it's queried. Make it immutable. Your future self — and your future regulator — will thank you. Number three: HITL for financial actions. This needs to be in your protocol, not your UI. The agent literally cannot execute without human approval. For a crypto platform, this is your trust model, not just your compliance checkbox. These three things. Wire them in first. Everything else follows."

Close + Q&A · 19:00–20:00

"You're building the future of AI agents.
The architecture you choose now
is the advantage you keep."

Trust isn't a feature you add. It's an architecture you choose from day one.

Neet (Clement Wong)

📧 clement@clementwong.me
🔗 linkedin.com/in/clementw
Happy to deep-dive any layer — threat model, compliance specifics, architecture review.

You bought ai.com.That's a platform bet.

OpenClaw on Cloudflare —The Three Layers

The question isn't who the user is.It's who the agent is.

How OpenClaw Connects —The Flow

Agents should be powerful.Not omnipotent.

If you can't see it,you can't trust it.