AI Agent Threat Model Template (OpenClaw Lab Example)

An AI agent threat model is a written record of what the agent can access, how that access could be misused, and which control limits each case. The template below has six sections. The worked example applies them to a single-user OpenClaw agent in a macOS virtual machine that Truvo Cyber built and tested in October 2026.

What does an AI agent threat model contain?

A complete model has six sections:

• Credentials: every credential the agent holds, with the scope, the storage location and the revocation method.
• Reach: the systems and tools the agent cannot use.
• Network exposure: the open ports and discovery paths, with a check and an expected result for each.
• Accepted risks: the weaknesses left in place, with the reason for each.
• Top risks: the most likely failures, each mapped to OWASP, with a mitigation.
• Kill switch: the ordered steps that stop the agent, with an owner and a recorded time.

We start with a map of the agent's components and connections. The scope and each control are tied to the map. For how to build one, see our agentic AI security architecture guide.

What credentials does an AI agent hold?

The lab agent is the OpenClaw setup from What Is OpenClaw?, configured with the 10 settings in our Mac setup guide. The lab agent holds three credentials. The configs, diagrams and full threat model are in the open lab repository under CC BY 4.0 and MIT licenses.

Two details in the table need a note:

• The secret store is not encrypted. The agent, the CLI and the UI can write to the store but never read from the store, yet the store is an unencrypted SQLite file that the VM user can read.
• Clones copy the credentials. Every clone of the VM holds all three credentials.

So we revoke credentials at the source (the cloud console or the Slack app settings) and delete the clones when the experiment ends. For more on agent identity, see AI agents and identity security.

What can an AI agent not reach?

We kept four things out of the agent's reach:

• Host files and accounts. The agent runs in a VM with no shared folders and no Apple ID, so the Mac's files, browser sessions and keychain are unreachable.
• Powerful tools. Shell, files, web, browser, nodes, automation and sub-agents are denied, and code mode is off.
• Inbound connections. The gateway listens only on loopback, Slack connects outbound over Socket Mode, the host firewall is on, and SSH from the host is key-only.
• Third-party skills. None are installed. To vet a skill first, read our MCP and agent skills security guide.

How do you verify the network exposure of an AI agent?

We ran each check below from a second device. Traffic from the Mac to the Mac's own address never leaves the Mac, so a test run on the Mac itself shows nothing about other devices.

In the lab, the Lume VNC server answered on the Mac's network address as well as on localhost, and Lume has no setting to change that. After we turned on the macOS firewall and blocked incoming connections to Lume, a VNC connection from an iPad on the same network failed.

Which risks does the team accept when building an AI agent?

We accepted three risks and wrote down the reason for each:

• Automatic login for the VM user. OpenClaw installs as a macOS LaunchAgent, which needs a logged-in session. macOS stores the password in /etc/kcpassword, obfuscated but not encrypted. Reason: the VM screen is reachable from the host only.
• Service account key readable by the VM user. The agent has no file or shell tools, so the agent cannot read the key. Anything else running as the VM user can.
• VM user is an admin inside the VM. Keep a passphrase on the account, because an empty password gives anything running as that user an easy path to root.

Writing accepted risks down is the control. An auditor reviewing SOC 2 CC3.2 or ISO 27001 clause 6.1.2 looks for named risks, each with an owner and a decision.

Which AI agent risks come first, and how do they map to OWASP?

We recorded six top risks and mapped each one to the OWASP Top 10 for Agentic Applications 2026 (ASI) and the OWASP Top 10 for LLM Applications 2025 (LLM).

What changes before an AI agent gets a shell?

A shell changes the threat model because of one setting. OpenClaw's sandbox is off by default, which we confirmed with openclaw sandbox explain. With the sandbox off, shell commands:

• run as the VM user,
• can read the service account key and the secret store database,
• can reach the internet.

A messaging-only agent has no commands to run, so the setting only matters once the runtime tool group is enabled. Before enabling that group, we plan four changes:

• Set exec security to allowlist or ask. The openclaw security audit command flags full.
• Run commands in a sandbox backend, or on a separate disposable machine over SSH that holds only what the job needs.
• Keep web access off for any agent that holds private data.
• Add a row to the credentials table for every new key.

We have not tested the shell-enabled configuration yet. We will add the results after the sandbox on-versus-off test.

What is the kill switch for an AI agent?

To stop the lab agent and cut off every credential, we take three steps in this order:

1. Stop the VM with lume stop.
2. Revoke the credentials at the source: the Google Cloud service account key first, then the Slack app or both Slack tokens.
3. Restore the clean clone before any restart.

Figure: kill switch order for an AI agent. Click the diagram to enlarge it.

What is the next step after writing an AI agent threat model?

Anyone can reuse the threat model template, the tested configs and both diagrams from our lab repository, and we welcome issues and corrections there. Truvo Cyber builds and reviews threat models for AI agents as part of security architecture engagements.

Frequently Asked Questions

What is an AI agent threat model?

An AI agent threat model is a written record of what an agent can access, which attacks could misuse that access, and which control limits or detects each attack. The record includes credentials, reachable systems, network exposure, accepted risks and the shutdown procedure.

How is threat modeling an AI agent different from threat modeling an application?

An agent chooses tool calls from text inputs, so any content the agent reads can steer the actions the agent takes. A threat model for an agent therefore adds a row for each input source (messages, web pages, files) and for each tool, on top of the usual data flows. OWASP classifies this case as ASI01 Agent Goal Hijack and LLM01 Prompt Injection.

Should the threat model use OWASP or MITRE ATLAS?

Both are useful. OWASP organizes risks by category, which suits a risks table, while MITRE ATLAS catalogs adversary techniques, which suits red-team planning and detection rules. We used OWASP for the lab model because OWASP's risk categories pair directly with controls.

How often should an AI agent threat model be reviewed?

Review the model after every agent software update, every new tool or credential, and every new data source. We re-check each setting in the lab after every OpenClaw update, because a new default can add a tool that the deny list does not cover.

Does a threat model count as audit evidence?

A dated threat model with named risks, owners and decisions is evidence for the SOC 2 risk assessment criteria and for the ISO 27001 risk assessment requirements. The credentials table and the network check results are also evidence for access control (SOC 2 CC6.1, ISO 27001 A.5.15).