Permission Boundaries and Credential Isolation

Stop Giving Your Agent the Master Key

🔄 Quick Recall: Last lesson, you containerized your agent with 5 Docker hardening flags. The container limits what the agent can do to the system. But inside that container, the agent still has access to everything you’ve given it — and most people give it far too much.

The Argus Security audit of OpenClaw found that OAuth tokens were stored in plaintext JSON files without encryption. File permissions were set to 0o600 (owner-only read/write), but since OpenClaw runs as the file owner, every skill loaded by the agent can read those tokens.

512 vulnerabilities. 8 critical. And the most fundamental one was this: the agent has the same access as you.

By the end of this lesson, you’ll be able to:

• Apply least privilege to AI agent configurations
• Set up credential isolation so the agent never handles raw secrets

The Problem: Your Agent Is You

When you give an AI agent your API key, you’re not giving it “some access.” You’re giving it YOUR access. The same permissions, the same scope, the same blast radius.

If that key can read and write to your production database, so can the agent. If a malicious skill exfiltrates that key, the attacker gets your full database access. Not the agent’s access — YOUR access.

NIST’s 2026 RFI on AI agent security put it clearly: agents should follow “least privilege and zero trust architecture.” The agent gets the minimum access needed for the specific task, verified at every step.

Principle 1: Scoped Tokens

Instead of giving the agent your master key, create tokens scoped to exactly what the agent needs.

Example: Email integration

Start with the most restrictive scope. If the agent needs more, add it explicitly — don’t start broad and hope to narrow later.

Example: File system access

# Instead of mounting your entire home directory:
volumes:
  - ~/:/app/home:rw  # DON'T DO THIS

# Mount only the directory the agent needs:
volumes:
  - ~/projects/current:/app/workspace:rw
  - ~/documents/reference:/app/reference:ro  # Read-only

Every mounted volume is a potential attack surface. Each one should be justified.

✅ Quick Check: Your agent needs to summarize files from your Documents folder. What’s the correct volume mount? (Answer: ~/Documents:/app/docs:ro — read-only access to only the Documents folder. The agent can read files to summarize them but can’t modify, delete, or access anything outside that directory.)

Principle 2: Credential Isolation

Credentials should never exist inside the agent’s context. Composio’s Managed Auth approach demonstrates the pattern:

1. Credentials live in a separate service (secrets manager, vault, or auth proxy)
2. The agent requests actions (“send this email”) without ever seeing the token
3. The auth service executes the action using credentials the agent can’t access
4. Audit logs record what was requested and what was executed

This is the gold standard. Even if the agent is fully compromised, the attacker never gets the credentials — they can only make requests through the auth service, which enforces its own policies.

For personal use, a simpler version:

# Instead of passing API keys as environment variables:
OPENAI_API_KEY=sk-abc123  # Agent can read this

# Use a proxy that injects authentication:
# Agent calls http://localhost:8080/api
# Proxy adds the API key header before forwarding
# Agent never sees the key

The proxy acts as a credential boundary. The agent talks to the proxy. The proxy handles authentication. A malicious skill can’t extract keys it never receives.

Principle 3: Just-In-Time Access

CyberArk’s framework treats AI agents as identities — like employees who need building access. The key insight: don’t give permanent credentials. Give temporary ones.

Just-In-Time (JIT) access works like this:

1. Agent needs to access a resource
2. Agent requests permission from a governance service
3. If approved, the agent gets a temporary token (expires in minutes)
4. The token is automatically revoked after the task completes

For personal use, this translates to:

• Don’t leave all API keys active all the time. Disable keys when you’re not actively using the agent.
• Use token rotation. If your agent’s tokens are compromised, short-lived tokens limit the exposure window.
• Review active sessions. Periodically check what tokens are active and revoke any you don’t recognize.

✅ Quick Check: You’re going on vacation for a week and won’t use your AI agent. What should you do with its credentials? (Answer: Revoke or disable all active tokens. When you return, create new ones. A week of idle credentials is a week of exposure if any were compromised. JIT access means credentials only exist when needed.)

Principle 4: Action Allowlists

Instead of trusting the agent to use tools responsibly, define exactly which tools it can use:

# Default-deny: agent can only use explicitly allowed tools
allowed_actions:
  - read_file
  - write_file
  - web_search

# Explicitly blocked (even if allowed_actions is broader)
blocked_actions:
  - shell_execute
  - delete_file
  - send_email
  - browser_control

Auth0’s security guide recommends “default-deny for high-risk actions: shell execution, browser control, recursive deletes.” The agent should never be able to execute shell commands unless you’ve explicitly decided it needs to.

This connects directly to OWASP A1 (Tool Misuse) and A2 (Excessive Agency) from your threat model. The allowlist is the implementation of those controls.

The granularity spectrum:

Start at the allowlist level. Move to action-level control for sensitive deployments.

Putting It All Together

Here’s a permission boundary configuration combining all four principles:

1. Scoped tokens: Agent-specific API key with read-only access to one project

2. Credential isolation: API key lives in a proxy, agent never sees it

3. JIT access: Token expires after 4 hours, auto-renewed only when agent is active

4. Action allowlist: Only file read/write and web search allowed; no shell, email, or browser

This configuration dramatically reduces the blast radius. If a malicious skill compromises the agent:

• It can’t get your credentials (isolation)
• It can’t run shell commands (allowlist)
• It can only access one project directory (scoped token)
• And the token expires in hours anyway (JIT)

Compare that to the default: attacker gets your personal API keys, full shell access, all your files, and permanent credentials.

Key Takeaways

• Your agent has YOUR access — a compromised agent means a compromised you
• Scoped tokens limit blast radius: agent-specific, read-only, project-specific
• Credential isolation means the agent never touches raw secrets — use a proxy or secrets manager
• Just-in-time access means credentials exist only when needed — revoke when idle
• Action allowlists define exactly which tools the agent can use — default-deny for shell, email, browser
• Combine all four for defense in depth: even if one layer fails, the others contain the damage

Up Next

Your agent is contained (Docker) and constrained (permissions). But what about the skills you install? A single malicious skill can bypass all your careful configuration. The next lesson teaches you how to vet skills before they vet you — the 5-point framework that separates safe skills from trojan horses.