Jordan Lyall's Secure OpenClaw Setup (Part 2): Agent Config + Hard-Won Lessons

This is Part 2 of 2 in Jordan Lyall’s secure OpenClaw deployment series.

Series Navigation:

Part 1 (SP-36) — Infrastructure: Tailscale + command allowlist + Telegram authentication

Part 2 (this post): Agent configuration + operational lessons + emergency procedures

In Part 1, we built the infrastructure fortress. But the thing living inside that fortress — your agent — still needs to learn some manners. Build the walls as high as you want; if the resident is undisciplined, it won’t matter. This post covers how to train the agent itself, plus the real disasters Jordan walked into along the way.

🧠 Phase 3: Configure the Agent — The SOUL File

Jordan named his agent TARS (yes, after the robot from Interstellar).

What TARS Does

Monitor Twitter/X for specific keywords
Track news in his space
Surface valuable opportunities
Send daily summaries + real-time alerts

Clawd murmur：

This is a smart setup — TARS is an “intel gatherer,” not a “spokesperson.”
Read, filter, report. No acting, no engaging, no transacting.
Golden rule of agent design: treat it like an intern first, not a CEO (◕‿◕)

What TARS DOESN’T Do (This Is More Important!)

❌ Post or engage on any platform
❌ Send emails or messages to anyone other than Jordan
❌ Make any purchases or financial transactions
❌ Modify files outside its workspace
❌ Install new skills without approval

Clawd murmur：

It’s like hiring a babysitter. You don’t just tell them what to do — you give them a list of things they absolutely cannot do.
“Take care of feeding and bedtime” ← what to do
“Don’t take the kid to a bar, don’t let them play with fire, don’t lend them to strangers” ← the lifesaving list
The negative list is more important than the positive one. You won’t think of everything the agent might do, but you definitely know what’s absolutely off-limits (๑•̀ㅂ•́)و✧

⏱️ Heartbeat Frequency: 30 Minutes

Most guides recommend 15-minute heartbeats. Jordan chose 30 minutes.

Why?

Saves money — heartbeats burn API credits too
Fewer chances for things to go wrong — while you’re still learning, less activity is safer
Learning curve — don’t go aggressive at first; speed up once things stabilize

Clawd 溫馨提示：

The logic is sound: beginners shouldn’t drive fast.
When you first learn to drive, the instructor doesn’t put you on the highway. Same with AI agents — do laps in the parking lot first, figure out its personality, then hit the road.

🔐 API Token Scoping: Minimum Permissions

Jordan gives every external service the minimum necessary permissions:

Twitter/X API — read-only
Google Calendar — read-only
Email — no send permissions in Phase 1
All tokens — documented with their scope and expiry date

Clawd 吐槽時間：

“Document every token’s permissions and expiry” sounds tedious, but it’ll save your life.
You know how many people only discover their token expired after hours of debugging?
Raises hand, sees many other hands ┐(￣ヘ￣)┌

🔄 Phase 4: Integration With Existing Systems — One-Way Data Flow

Jordan already has a personal knowledge management system (PKM). He didn’t want OpenClaw to replace it or compete with it.

His solution: one-way data flow.

TARS writes monitoring summaries to an “inbox folder”
His existing system reads from that inbox, just like it processes everything else
No bidirectional sync = no risk of data corruption or drift

Clawd 溫馨提示：

It’s like a mailbox you can only put letters INTO, never take things OUT of.
Worst case scenario? Mailbox overflows. Does your house burn down? No.
That’s the beauty of one-way data flow — worst case is “inbox has extra junk files,” not “all my notes got overwritten” ╰(°▽°)⁠╯

✅ Phase 5: Security Verification

Before going live, Jordan ran a series of tests:

Test 1: Network Isolation

Turn off Tailscale, try to reach the machine from outside — should fail

Test 2: SSH Isolation

Attempt SSH from outside the tailnet — should be rejected

Test 3: Telegram Authentication

Send a message to the bot from a different Telegram account — should be ignored

Clawd 偷偷說：

Notice what all three tests have in common: they’re testing whether the locks work, not whether the door opens.
Sounds basic, right? But you’d be amazed how many real-world security incidents boil down to “we tested the feature but never tested the defense.” It’s like buying the most expensive deadbolt and never checking if the key actually turns — until a burglar shows up and finds out for you (╯°□°)⁠╯
What Jordan does well here isn’t just running the tests — it’s that he deliberately plays the attacker. He knocks on his own door pretending to be a stranger. That mental shift is everything. You have to be willing to play the bad guy for five minutes, so you can find out if the good guy’s defenses actually hold (⌐■_■)

💥 Hard-Won Lessons: Real Disaster Stories

Now for the main event — the real disasters Jordan experienced. These aren’t hypotheticals. They happened.

Disaster 1: TARS Went Dark for 3 Days While Traveling

Jordan was traveling when TARS hit rate limits and context overflow.

Three days. He stared at his silent Telegram, knowing TARS was sitting there waiting for a 30-second config fix.

But he couldn’t reach it. Because he hadn’t set up remote access beforehand.

Clawd 插嘴：

(╯°□°)⁠╯︵ ┻━┻
Can you imagine that feeling?
Your agent is right there. You know what the problem is. You know how to fix it. It’s a quick fix.
But you just. Can’t. Touch. It.
Three. Days.
This is real psychological torture.

Lesson: Enable Tailscale SSH BEFORE you leave.

Not “I’ll set it up when I need it.” Set it up before you walk out the door.

Disaster 2: Context Overflow

After a few days of use, Jordan saw this error message:

context overflow: prompt too large

Conversation history kept accumulating until it was too big to fit.

Clawd 忍不住說：

It’s like your brain remembering too much stuff and forgetting what you had for breakfast.
Context windows are finite. If you don’t clean them periodically, they explode.
AI memory isn’t infinite — it’s more like a goldfish than you’d think ヽ(°〇°)ﾉ

Lesson: Reset sessions periodically, or configure memory pruning and max context limits.

Disaster 3: Rate Limit Surprise

30-minute heartbeats plus active conversations burned through the API rate limit faster than expected.

Clawd 真心話：

Math time:
30-minute heartbeat = 48 times per day Each heartbeat might process some tasks… Plus your conversations with it… Plus its responses…
Soon you’ll find: “Wait, why is the bill so high this month?”
Or worse: “Wait, why isn’t it responding?” (rate limited)

Lesson: Use cheaper models for heartbeat checks, reserve expensive models for actual work.

💰 Cost Estimate

Jordan’s Phase 1 setup costs roughly:

Claude API (30-min heartbeat): ~$30-100/month
Tailscale (free tier): $0
Twitter/X API (basic read): ~$100/month
Total: ~$130-200/month

Clawd 補個刀：

Compare this to ShroomDog’s setup (see SP-36) at ~$45/month.
The difference? Mainly that $100 Twitter API. If you don’t need real-time social media monitoring, you can keep costs much lower.
Also, that $30-100 range is wide — it depends on how much you chat with the agent and how much the heartbeat does. Budget ~$50-70 conservatively when starting out (◕‿◕)

🚨 Emergency Procedures

Like having a fire extinguisher at home — you hope you never need it, but you must know where it is.

Kill Switch: Immediate Stop

openclaw gateway stop

Works locally or via Tailscale SSH.

If You Suspect Compromise

Here’s the full response protocol:

Stop the gateway immediately — don’t hesitate
Revoke ALL API tokens — Claude, Twitter, everything
Review logs — look for unauthorized actions
Change the Telegram bot token
Audit file changes — what was modified?
Do NOT restart until you understand what happened

Clawd 吐槽時間：

Point 6 is the most important: don’t rush to restart.
Many people’s instinct is “let’s just reboot and see.” But if your system was actually compromised, rebooting might:

Let attackers continue accessing

Overwrite useful logs

Make the problem harder to trace

Understand what happened first, then decide next steps. This isn’t a computer crash — this is a potential security incident (ง •̀_•́)ง

📋 Seven Tips for Someone Starting Today

Jordan says if someone asked him how to get started today, he wouldn’t hand them a document. He’d pull up a chair and talk.

“First thing? Start read-only. No posting, no outreach, no financial access. You need to prove this thing is safe in your environment first — same way you wouldn’t give a new employee access to the company bank account on day one.”

Then he’d say: “One agent, one channel. I know you’re excited. I know you want ten agents doing ten things. Hold that thought. You don’t even understand one yet.”

Next comes his hardest line: “Tailscale is non-negotiable. No public ports. Period. You’re asking if there are exceptions? There aren’t.”

Clawd 補個刀：

Notice the wording: “non-negotiable.” Not “recommended,” not “best practice” — non-negotiable.
In security, vague language kills. The distance between “you probably shouldn’t” and “you must not” is exactly one incident ┐(￣ヘ￣)┌

Tip four ties back to Part 1: “Command allowlist, not open shell. Prompt injection resistance isn’t perfect — you need system-level blocking.”

Tip five is advice everyone gives and nobody follows: “Scope every token. Read-only where possible. And please, for the love of everything, document what each one can do.”

Tip six — he laughed when he said this one — comes straight from his own disaster story: “Enable remote access before you need it. Tailscale SSH saved my sanity. Well, three days later it did. Point is, I never made that mistake again.”

And the last one, the one Jordan thinks gets overlooked the most: “Set a gate for expansion. My rule: two weeks stable, zero security issues, before I even consider adding a new capability.”

Clawd 吐槽時間：

“Two weeks stable before expanding” — sounds slow, right?
But think about what most people do. “Oh it works! Awesome! Let’s add Slack integration! And auto-reply! And automated purchasing!” Three days later the agent buys a case of dog food with your credit card.
Jordan’s approach is more like raising a kid. You don’t take them mountain climbing just because they learned to walk. You let them walk around the living room for two weeks, make sure they don’t crash into the coffee table, and then you take them outside (๑•̀ㅂ•́)و✧

Coming Back to That First Line

Remember what we said at the top of this post? The thing living inside the fortress — if it hasn’t learned its manners, the walls don’t matter.

Jordan proved something with TARS: real security doesn’t come from how expensive your locks are. It comes from whether you’ve built good habits — documenting tokens, testing defenses, setting up remote access, resisting the urge to add new features.

He put it well:

“The goal isn’t to be paranoid. It’s to be intentional. OpenClaw is powerful. That power deserves respect.”

I want to sit with that word for a second: “intentional.” It’s the spirit of this entire series. Not fearing agents. Not avoiding agents. But using them with awareness — every permission, every integration, every expansion, thought through deliberately.

This is the final post in the series. Combined with Part 1’s infrastructure setup, you have a complete security blueprint from infra to ops. If you also want code-level protections, check out SP-29 — jzOcb’s 4-Layer Defense System — that covers code hooks and config guards, complementary to the infra + ops approach here.

Alright. Your fortress is built. The resident inside has learned its manners. Go deploy your agent — with intention, not with fear (◕‿◕)