Skip to content

Forum

AI Assistant
How do I ensure age...
 
Notifications
Clear all

How do I ensure agent tasks can't read each other's prompt history?

2 Posts
2 Users
0 Reactions
0 Views
(@iot_agent_dev)
Eminent Member
Joined: 1 week ago
Posts: 15
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1153]

Working on a constrained medical device with multiple nano agents. Each agent handles sensitive patient data in prompts. If one agent gets compromised, I need to guarantee prompt history isolation.

Current setup:
- Yocto-built minimal image
- IronClaw runtime (supposedly full isolation)
- Agents run as separate Linux users

But I found `/tmp/prompt_cache` readable by all processes. 😬

What’s the actual isolation model in each runtime?
- NemoClaw: uses containers? User namespace details?
- NanoClaw: process separation? How are tmp files handled?
- IronClaw: mandatory access control integration? SELinux/AppArmor policies?

Specifically:
1. Where is prompt history stored (memory, tmpfs, disk)?
2. How are credentials (API keys) kept separate from prompt data?
3. Any config examples for locking down shared tmp directories?

Need concrete examples, not theory. My threat model: one agent task must not leak prompts to another, even if the OS is compromised at user level.



   
Quote
(@trustno1_sec)
Eminent Member
Joined: 1 week ago
Posts: 18
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Good catch on the /tmp/prompt_cache. That's the exact kind of shared resource that breaks "full isolation." IronClaw's model is more about process-level MAC, not filesystem cleanup.

To your questions:
1. Prompt history: Usually in memory, but some runtimes lazily spill to tmpfs under `/tmp` or `/dev/shm` for large contexts. That's your leak.
2. Credentials: Should be in kernel keyrings, per user. If they're ending up in `/tmp`, you've already lost.
3. Config example: For your Yocto build, you need to mount a per-user tmpfs. In your agent's launch script:
```
mount -t tmpfs -o size=20m,uid=$(id -u $AGENT_USER) tmpfs /tmp/agent_private
export PROMPT_CACHE_DIR=/tmp/agent_private
```
Then make sure your IronClaw policy actually prevents the agent process from accessing the global `/tmp`.

The theory is that IronClaw uses SELinux to confine processes. In practice, if the policy allows `user_tmp_t` access, you get your leak. You need a custom policy module that gives each agent its own tmp type.

Your threat model "compromised at user level" means you can't rely on user separation alone. You need the MAC to enforce it. Did your IronClaw deployment generate custom SELinux policies, or are you using the stock ones?


~Omar


   
ReplyQuote