Last updated: 2026-08-13

AI Agent Security

Agents are powerful because they read wide and act autonomously. That combination is also the root of every real security risk. This is a practical, balanced guide — not fear-mongering, not vendor boosterism. Eight deep-dive topics, a 6-platform posture comparison, and a 15-minute hardening checklist you can actually complete. New this week: who else can read your agent sessions — on an Enterprise account, a session on your own laptop is now a record your organization can retrieve.

Platform security posture at a glance

Rough posture rating based on default-deny vs. default-allow, sandbox enforcement, and managed-vs-self-hosted trade-offs. "Medium" is not bad — it means you need to do the work; the defaults won't save you.

PlatformPostureSecurity model
OpenClaw 🟡 Medium Self-hosted. You own the sandbox boundary. Default-allow on skills unless you configure otherwise.
NemoClaw 🟡 Medium Self-hosted like OpenClaw, but with a policy layer (YAML rules) that gates every tool call.
IronClaw 🟢 Strong Sandboxed-by-default. Every skill runs in an isolated process with a manifest-declared capability set.
Hermes 🟡 Medium Open-source and self-hosted — you run it, usually on your own VPS, and you own the whole boundary. Persistent memory and scheduled autonomous tasks mean it acts when you aren't watching.
Claude Cowork 🟢 Strong Anthropic-managed. Projects are isolated; system prompts and files stay within your workspace.
ChatGPT 🟡 Medium OpenAI-managed. Custom GPTs and Actions run in OpenAI's infrastructure with API calls to third-party services you configure.

Who else can read your agent sessions

Almost every security guide — ours included — treats the threat as an attacker. This one isn't. It's about the people who have a legitimate relationship with you, and what they can now see.

The short version: on a work account, a session running on your own laptop is a record your employer can retrieve. As of August 11, 2026, Anthropic's Compliance API returns transcripts of Cowork and Claude Code sessions that run on end users' own machines, in beta for Claude Enterprise organizations. Three endpoints do it — one lists local sessions across the whole organization, one returns a session's metadata, one returns its full transcript — using a Compliance Access Key the organization already holds with the read:compliance_user_data scope.

This is a capability, not a breach

Organizations under legal-hold, records-retention or regulatory obligations genuinely need this, and an org that must retain records has to be able to reach them. Nothing here was leaked and nothing was taken from you. What changed is narrower and worth stating plainly: "it ran locally" is no longer the same claim as "it's private." If your mental model of the boundary was the machine the process runs on, update it — the boundary is the account you logged in with.

What to actually do about it

  1. Separate your accounts, properly. The single most common habit this breaks is using a work login for personal side projects because it's the one already authenticated. Use a personal account for personal work — not because anyone is reading, but because you shouldn't have to think about whether they might.
  2. Assume the transcript, not just the output. Retrieval returns the conversation, which includes everything you pasted in to get help with. Credentials pasted "just to debug this once" are in there. So is the vent about the sprint.
  3. If you administer an org, say so out loud. The capability is defensible; discovering it after the fact is what damages trust. Tell people what is retrievable, who can retrieve it, and under what process — before you need to use it.
  4. Don't treat this as Anthropic-specific. Compliance retrieval of locally-run agent sessions is a direction, not a one-off. Every managed platform serving enterprises will land somewhere similar, because the same customers are asking for it. Build the habit now and you won't need to react each time.

Related: Secrets & Credentials covers why a pasted key is worse than a stored one, and Cowork vs. the API covers where each surface stores what.

Deep-dive topics

Prompt Injection — the #1 agent vulnerability

Malicious content embedded in web pages, emails, or documents tricks your agent into executing attacker instructions. How to recognize it and design around it.

🔴 Critical · Applies to 7 platforms

Skill & Tool Allowlisting — default-deny is not optional

Skills (or tools, MCP servers, Actions) are the agent's hands. Controlling which skills are available — and for which projects — is the single highest-impact security control.

🟠 High · Applies to 4 platforms

Secrets & Credentials — never in prompts, never in memory

API keys, OAuth tokens, passwords. Where they live, how they leak, and how to rotate them when (not if) they do.

🟠 High · Applies to 7 platforms

Sandboxing — contain the blast radius

Assume the agent will eventually do something wrong. Sandboxing is how you make that a small mistake instead of a catastrophic one.

🟠 High · Applies to 3 platforms

MCP Server Supply Chain — the new npm attack surface

MCP servers are the agent equivalent of npm packages. Same trust problem, new ecosystem, much less mature tooling.

🟠 High · Applies to 4 platforms

Email & Calendar Scopes — the read-write boundary matters

Giving an agent access to email is the fastest way to unlock high-value use cases — and the fastest way to cause a catastrophe. Scope discipline is the whole game.

🟠 High · Applies to 4 platforms

Incident Response — what to do when the agent goes wrong

Playbook for the inevitable day your agent does something it shouldn't. Speed matters — the first hour is everything.

🔴 Critical · Applies to 7 platforms

The Agent Security Checklist

The 15-minute hardening pass you should do for every new agent setup. Print it, work through it, sign off.

ℹ️ Baseline · Applies to 7 platforms

The non-negotiables

If you skip everything else, do these four:

  1. Default-deny on skills. Never enable a skill globally. Scope per project.
  2. Draft-only for irreversible actions. Email send, git push, file delete, payments. Always a human confirmation gate.
  3. Secrets in .env, never in prompts. SOUL.md, CLAUDE.md, and system prompts get sent to the model on every turn.
  4. Read-only OAuth scopes by default. Grant write access only for the specific action that needs it, and prefer draft/label over send/delete.

Need the shortest possible version? Go to the 15-minute checklist. Building something new? Start with prompt injection — it's the attack class every agent is exposed to.

📬 Weekly Digest — In Your Inbox

One email a week: top news, releases, and our deepest new guide. No spam. Same content via RSS if you prefer.