OpenClaw’s broad access shows why agent gateways matter

At a glance

What this is: This is a Tailscale blog post arguing that OpenClaw’s default autonomy and credential handling make AI agents risky without stronger access controls and observability.

Why it matters: It matters because practitioners managing AI agents, MCP credentials, and adjacent NHI controls need to treat agent access, exposure, and cost controls as governance problems, not just deployment choices.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 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.

👉 Read Tailscale's analysis of OpenClaw risk and access control

Context

OpenClaw is a useful example of a wider governance problem in agentic AI: once an agent is allowed shell, file, and network access, the boundary between experimentation and operational risk narrows quickly. In practice, the issue is not simply model quality, but the combination of autonomy, secrets exposure, and external connectivity. For AI agent identity and NHI governance, that creates a control problem around who or what is allowed to act, with what credentials, and under what scope.

Tailscale’s discussion also shows how quickly agent risk becomes an identity and access issue. The article’s emphasis on API keys, MCP credentials, and network exposure maps directly to NHI governance because these are machine-consumable credentials being placed inside a runtime that can make non-deterministic decisions. That starting point is increasingly typical for teams experimenting with AI agents, which is exactly why the control gaps deserve scrutiny before production use.

Key questions

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. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

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. Governance has to measure what the agent actually did with the data, not only whether the agent was allowed to see it. That is why lineage and activity evidence matter.

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. Signs of trouble include unexpected record access, unapproved action types, new system paths after an update, or repeated attempts to exceed the intended scope. In healthcare, behaviour review matters as much as entitlement review because unsafe actions often appear first as workflow drift.

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.

Technical breakdown

Why plaintext API keys are dangerous in agent runtimes

Agent runtimes often need credentials to call models, tools, and external services. When those credentials are stored in plaintext configuration files, the security boundary becomes the host itself, not the agent. That is a poor fit for systems that can browse, execute commands, and interact with untrusted content. A prompt injection, accidental commit, or simple file read can expose secrets that were meant to stay outside the agent's reach. In NHI terms, the problem is not just secret storage, but secret proximity to an unconstrained runtime.

Practical implication: keep model and tool credentials outside the agent host wherever possible, and remove any plaintext secret path from the deployment model.

How agent gateways change visibility and control

An AI gateway sits between the agent and the services it wants to reach, giving operators a chokepoint for logging, quota enforcement, and request inspection. That does not make the agent safe, but it does convert invisible behaviour into governable behaviour. The article’s discussion of tool calls, tokens, and cost caps shows why observability matters: once an agent can chain decisions across multiple tools, the real risk is often not a single bad prompt but an unbounded sequence of actions. Gateways are therefore as much about accountability as they are about cost control.

Practical implication: route agent traffic through a control point that logs requests, enforces budgets, and records which tools were called.

Serve versus funnel: the exposure model matters

Tailscale’s distinction between serve and funnel is a network governance issue, not just a convenience choice. A tailnet-restricted service keeps the agent reachable only to devices already inside a controlled network boundary, while funnel exposes it to the public internet. For an AI agent with shell access and credentials nearby, public exposure creates an unnecessary attack surface for prompt injection, data leakage, and tool misuse. This is especially relevant where the agent is not fully trusted, because network reachability and capability scope should be treated as separate controls.

Practical implication: keep experimental agents off public exposure by default and use network boundaries to constrain who can reach them.

Threat narrative

Attacker objective: The attacker objective is to induce the agent to reveal credentials or perform unauthorised actions that expand access beyond the intended scope.

1. Entry occurs when an AI agent is deployed with shell, file, and network access plus externally reachable services or plaintext credentials.
2. Credential access follows when prompts, config files, or tool interactions expose API keys, MCP credentials, or other sensitive tokens.
3. Escalation happens when the agent uses those credentials to call additional tools, reach external APIs, or take actions beyond the operator's intent.
4. Impact is secret leakage, uncontrolled external execution, or unauthorised access to connected systems and data.

NHI Mgmt Group analysis

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.

Plaintext credential handling creates an avoidable exposure window for agentic systems. The article’s discussion of API keys in local configuration files highlights a failure mode that is familiar in secrets governance but more dangerous in autonomous runtimes. If the agent can inspect its own environment or be influenced by untrusted input, the secret is too close to the workload. The better framing is standing credential exposure window, because the risk begins before any malicious action occurs.

Visibility and quota controls are becoming a minimum viable control plane for AI agents. The ability to see tool calls, token use, and cost buckets is not just about billing discipline. It is also a way to constrain blast radius when an agent behaves unexpectedly or loops through unplanned actions. That aligns with NIST AI RMF GOVERN and MANAGE thinking, where accountability and runtime control matter as much as initial approval. Practitioners should insist on auditable agent activity before wider rollout.

Network exposure should be treated as part of agent privilege, not a separate deployment setting. The serve versus funnel distinction shows how easily an agent can move from contained to internet-reachable. For AI systems that can access credentials or external APIs, network reach is an extension of privilege. This is where agentic AI governance intersects with ZTA and workload identity thinking: constrain connectivity, scope access tightly, and separate experimentation from production exposure.

The market is moving toward controls that govern behaviour at runtime, not just assets at rest. Agents are dynamic systems, so static approval and one-time review are insufficient when access paths can change per task. That means the category is converging on gateways, policy enforcement, and telemetry as core controls. Practitioners should expect agent governance to look less like traditional software deployment and more like continuous identity supervision.

What this signals

Agent governance is converging on runtime identity controls. As agents begin to sit between users, tools, and data sources, static access reviews will not be enough to explain or contain their behaviour. Teams should expect more pressure to link network boundaries, secret handling, and request telemetry into a single policy layer. For identity and security programmes, the practical task is to decide which agent actions are allowed before the agent ever touches a tool.

Standing credentials remain the easiest way for agentic systems to drift outside intent. The moment a secret is available in the same environment as an autonomous runtime, the attack surface widens from code execution to downstream access abuse. That is why secret handling, log retention, and tool-scoped authorisation need to be designed together, not separately. Teams that already manage machine identity should use that discipline to contain AI agent growth.

Visibility is becoming the control that separates experimentation from governance. If a programme cannot answer what the agent accessed, which tools it called, and how much it consumed, then it cannot support audit, incident response, or accountable deployment. That is why agent telemetry now belongs in the same conversation as IAM, PAM, and workload identity. The first operational milestone is not full autonomy, but observable behaviour.

For practitioners

• 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. Use that gateway to separate model access from direct host access and to enforce request visibility across teams.
• 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. Replace local plaintext configuration with scoped secret handling and rotate any key that has been present on an agent workstation.
• 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. Separate test sandboxes from anything that touches sensitive data or production services.
• Set cost and action quotas before broad rollout Define hourly, daily, and per-model spending caps alongside action limits so a runaway agent cannot keep chaining calls indefinitely. Pair those caps with alerting on unusual request volume, unexpected tool use, or repeated rejection events.

Key takeaways

• OpenClaw illustrates a broader agentic AI control gap: autonomy, credentials, and connectivity become dangerous when they are granted together.
• The strongest evidence point is that agent behaviour can be visible yet still unpredictable, which makes auditability and scope control essential rather than optional.
• Practitioners should treat gateways, private exposure, and secret isolation as baseline controls for AI agents before any broader rollout.

Key terms

• Agent gateway: The local or remote control layer that authenticates, pairs, and orchestrates an AI agent’s actions across connected tools. In practice it becomes an identity concentrator, because one gateway session can govern messages, commands, and downstream systems with far broader reach than the user interface suggests.
• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.
• Tailnet-restricted access: A network exposure model where a service is reachable only from devices already inside a controlled private network. For AI agents, this is a practical way to reduce attack surface, contain experimentation, and separate internal testing from public internet exposure.
• Agent telemetry: Operational data describing what an AI agent did, which tools it called, how much it consumed, and what resources it touched. Telemetry is essential for audit, incident response, and behavioural governance because agent decisions are otherwise difficult to reconstruct.

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

👉 Tailscale's full post covers the Aperture setup, quota controls, and exposure choices in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for teams building modern access controls. It gives practitioners a practical foundation for governing machine credentials and autonomous systems across their programmes.