Your agent has the keys to your kingdom — act like it

Your agent can read your emails, execute shell commands, and call APIs with your credentials. One bad prompt injection and someone else is doing the same thing.

I've been watching the NemoClaw security discussion blow up on X, and it's wild how many people are running agents with admin privileges and zero guardrails. Here's what you need to lock down today.

Start with deny-by-default execution

Your agent doesn't need sudo. It doesn't need to install packages. It doesn't need network access to every domain on the internet.

# ~/.agent/permissions.yaml
execution:
  allowed_commands:
    - git
    - npm
    - python
  blocked_commands:
    - sudo
    - rm -rf
    - curl
  max_execution_time: 30s

network:
  allowed_domains:
    - api.openai.com
    - github.com
    - your-app.com
  block_private_ips: true

Most frameworks let you whitelist commands and domains. Use them. Your agent can be plenty useful without being able to wget random executables.

Never copy credentials to client context

This one's huge. Your agent needs API keys to work, but it should never see the actual key values.

# Wrong - exposes credentials
response = agent.call("Send this email", context={
  "smtp_password": "actual_password_123"
})

# Right - use credential references
response = agent.call("Send this email", context={
  "smtp_credential_id": "email_sender"
})

Your agent runtime should resolve credential references server-side. The agent sees "email_sender", your system injects the real password behind the scenes.

Sandbox everything file-related

File access is where things get scary fast. One prompt injection and someone's reading your ~/.ssh directory.

Real example: An agent with read access to /home/user got prompt-injected through a malicious email. The attacker exfiltrated SSH keys, AWS credentials, and browser session tokens in under 2 minutes.

Create a sandbox directory. That's it. That's the agent's entire world:

# Agent can only touch files here
/home/agent-sandbox/
├── input/     # Files you want processed
├── output/    # Results go here
├── temp/      # Scratch space
└── tools/     # Approved scripts only

Use Docker, chroot, or your OS's built-in sandboxing. No exceptions.

Know the difference between CAN and SHOULD

Your agent can technically call your Stripe API to refund every customer. Should it? Obviously not.

Build permission layers:

• Technical permissions: What the agent's API keys allow
• Policy permissions: What your business rules allow
• Context permissions: What makes sense for this specific task

A customer service agent might have read access to billing data, but it should only use that access when the conversation is actually about billing.

Monitor everything

Log every command, every API call, every file access. Not just for debugging — for security.

[2024-01-15 14:23:01] EXEC: git status (allowed)
[2024-01-15 14:23:05] API: stripe.customers.list (allowed)
[2024-01-15 14:23:07] EXEC: curl malicious-site.com (BLOCKED)
[2024-01-15 14:23:08] FILE: attempted read ~/.aws/credentials (BLOCKED)

Set up alerts for blocked actions. If your agent is trying to access forbidden resources, something's wrong.

The goal isn't to neuter your agent — it's to give it exactly the power it needs and no more. A well-secured agent is actually more reliable because it can't accidentally break things.

Security isn't something you bolt on later. It's the foundation that lets you actually trust your agent with real work.