Notifications
Clear all
Topic starter
02/08/2026 11:52 am
TL;DR: OpenClaw’s default setup gives an AI agent shell, file, and network access while storing LLM credentials in plaintext, creating an obvious path to key leakage and uncontrolled external calls, according to Tailscale. The practical issue is not whether agents are useful, but whether organisations can govern their access, visibility, and exposure before they scale.
NHIMG editorial — based on content published by Tailscale: OpenClaw is fun. OpenClaw is dangerous. Here's where Tailscale helps
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: What breaks when AI agents are given broad standing access?
A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check.
Q: Why do AI agents create governance problems that normal access reviews miss?
A: AI agents can read, copy, transform, and re-share data after the original access decision, so a static review of entitlements does not capture downstream impact.
Q: How do security teams know if an AI agent is operating outside its approved role?
A: Teams should compare actual workflow behaviour against the approved use case.
Practitioner guidance
- Implement gateway-mediated access for AI agents Place model and tool requests behind a gateway that logs tool calls, token usage, and request metadata so operators can review behaviour after each run.
- Remove plaintext credentials from agent hosts Store LLM and MCP credentials outside the runtime where the agent can read files or inspect its own environment.
- Constrain agent exposure to private networks Keep experimental agents reachable only through a controlled tailnet or equivalent private boundary, and avoid public exposure for systems that can access files, shells, or external APIs.
What's in the full article
Tailscale's full blog covers the operational detail this post intentionally leaves for the source:
- How Aperture logs tool calls, token use, and cost data in practice for OpenClaw sessions
- How daily, hourly, total, and per-model cost caps are configured and enforced
- How Tailscale exposure modes differ between private tailnet access and public funnel exposure
- How the sample OpenClaw configuration routes model access through Aperture without storing keys locally
👉 Read Tailscale's analysis of OpenClaw risk and access control →
OpenClaw and agent access control: are your controls keeping up?
Explore further
02/08/2026 1:01 pm
Open agent access is an identity governance problem before it is an AI problem. Once an agent can execute commands, read files, and call external services, the question shifts from model performance to who or what is authorised to act. That places AI agents squarely inside NHI governance because the agent relies on machine credentials to operate. Practitioners should treat agent permissions as a governed identity surface, not an experimental convenience.
A question worth separating out:
Q: Who is accountable when an AI agent exposes credentials or changes identity state?
A: Accountability should sit with the business owner of the agent, the identity team that granted scope, and the control owner responsible for the affected workflow. If the agent touched privileged systems, incident handling should follow the same seriousness as any privileged access failure, because the issue is not just misuse but governance collapse across the identity layer.
👉 Read our full editorial: OpenClaw’s broad access shows why agent gateways matter
