TL;DR: AI agents can leak secrets, display PII, and execute destructive commands unless guardrails are enforced at the tool layer, not just in prompts or transcript scanning, according to Knostic. The deeper lesson is that agent security depends on runtime enforcement, because policy text alone cannot reliably stop harmful execution paths.
At a glance
What this is: This is a security walkthrough of openclaw-shield that shows where AI agent guardrails fail and why tool-layer enforcement matters.
Why it matters: It matters because practitioners governing AI agents need controls that stop harmful actions at execution time, not just rules that the model can ignore.
Context
AI agents that can read files, call tools, and run shell commands create a different governance problem from chatbots that only generate text. When those agents are allowed to act on behalf of users, the security question shifts from what they might say to what they can actually do with files, secrets, and system commands.
This post examines a layered guardrail design around OpenClaw agents and the failures that surfaced in the published runtime. The central issue for AI agent governance is that context instructions, output filtering, and logging are weaker than control points that sit directly in the execution path.
The article’s broader lesson is that agent security depends on where enforcement happens in the workflow. That starting position is typical for AI agent tooling: the hard part is not detecting risk after the fact, but stopping misuse before the action completes.
Key questions
Q: What fails when AI agent guardrails exist only in prompts and logs?
A: The control fails because prompts and logs are not enforcement points. An agent can still attempt or complete risky actions if it is allowed to read files, call tools, or execute commands before any denial occurs. Effective governance has to block the action at runtime, not just document the policy after the fact.
Q: Why do AI agents need runtime enforcement instead of relying only on upstream identity controls?
A: AI agents can decide and act dynamically inside the execution loop, so upstream authentication alone does not control every tool call or data request. Runtime enforcement reduces the chance that a valid identity can overreach its intended scope. This matters most when agents operate across changing contexts, multiple tools, and short-lived tasks that require continuous policy checks.
Q: How do security teams know whether an AI agent control stack is actually working?
A: Look for three things: every agent has a traceable identity, permissions are narrow enough to explain in operational terms, and actions can be audited end to end. If any of those are missing, the control stack is incomplete even if the data layer uses advanced privacy techniques. Identity, scope, and logging should all line up.
Q: What should teams do when AI agents are allowed to run shell commands?
A: They should scope tool permissions tightly and require a real approval or denial decision before any command is executed. The key governance point is that the agent must not be able to self-authorise destructive actions simply because it was prompted to act on a user’s behalf.
Technical breakdown
Why prompt-level policy blocks are weak for AI agents
Prompt guardrails influence the model’s behavior, but they do not create a hard security boundary. A policy block in context can be overridden by a direct user instruction, and it does not reliably prevent the model from attempting risky tool use. In agent systems, this matters because the model is not just generating text, it is selecting and sequencing actions. The security boundary has to exist where the action is authorized, not only where the instruction is written. Practical implication: treat prompt policy as advisory unless a separate execution control can deny the action.
Practical implication: treat prompt policy as advisory unless a separate execution control can deny the action.
How output scanning and transcript redaction work in agent pipelines
Output scanning is a post-generation control. It can remove secrets or mask PII before data is stored in the conversation history, but it does not necessarily stop the model from seeing raw values during the current turn. That distinction is critical. If the LLM has already consumed the secret, a later redaction only reduces persistence risk, not immediate exposure or misuse. For AI agent governance, this is the difference between containment and prevention. Practical implication: use output scanning to reduce residue, but do not mistake it for a control that prevents secret exposure to the model itself.
Practical implication: use output scanning to reduce residue, but do not mistake it for a control that prevents secret exposure to the model itself.
Why a tool-based security gate is stronger than observability hooks
A tool-based gate sits inside the agent’s action path and can return an explicit allow or deny decision before execution proceeds. That is fundamentally different from hooks that only observe, log, or transform data after the fact. The article shows why this matters: if the runtime does not actually invoke a hook, or invokes it too late, the control is bypassed even though it appears to exist in code. In identity terms, the decisive control point is issuance and authorization of the action itself. Practical implication: place security decisions on the executable path, not on passive telemetry or late-stage persistence hooks.
Practical implication: place security decisions on the executable path, not on passive telemetry or late-stage persistence hooks.
Threat narrative
Attacker objective: The objective is to make the agent reveal sensitive data or carry out harmful system actions that should never have been allowed.
- Entry occurs when a user prompts the AI agent to access files or execute commands on their behalf.
- Credential or data exposure follows when the agent reads files containing API keys, tokens, or PII and handles them inside the conversation flow.
- Impact occurs when the agent runs destructive shell commands or exfiltrates secrets through tool arguments or generated output.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime enforcement is the real control boundary for AI agents: This article shows that prompt text, logging, and post-processing do not constitute a reliable security boundary once an agent can read files and execute commands. The decisive question is whether the system can deny a risky action before the model or tool completes it. For practitioners, the control conversation starts at execution time, not at policy drafting.
AI agent security is now an authorisation problem, not just a content-safety problem: The exposed risk is not only that the agent may say the wrong thing, but that it may be permitted to do the wrong thing. That shifts governance toward action-level approval, scoped tool permissions, and auditable deny decisions. In practice, agent identity must be governed like a constrained executor, not a conversational assistant.
Hook definitions without hook invocation create a false sense of control: The article highlights a familiar governance failure in modern platforms, where the presence of a security extension point is mistaken for enforced protection. If the runtime never calls the hook, the control exists only on paper. Practitioners should treat advertised extension points as unverified until traced through the actual execution path.
Agent guardrails should be measured by blocked actions, not by policy coverage: A system can contain long policy text and still permit dangerous behaviour if the control does not sit on the tool path. The useful metric is whether destructive commands are denied, secrets are withheld, and sensitive values never reach the model in usable form. That shifts evaluation from configuration completeness to runtime outcome.
Tool-mediated denial is the named concept here: the security gate wins where passive inspection fails: The article demonstrates that an allow-or-deny tool call can stop harm because it changes the agent’s decision flow, not just its transcript. That is the governance pattern that matters for AI agents acting with delegated access. Practitioners should design for denial at the point of action.
From our research library:
- 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Tool-path governance is the practical boundary for agent safety: AI agent programmes should assume that prompt instructions will be bypassed eventually, so the control design has to move to the point where the action is authorised or denied. That is especially true for file access, command execution, and secret handling.
Security gates are more defensible than passive inspection for agentic workflows: Once an agent can choose when to act, controls that merely observe transcripts or redact outputs arrive too late to change the outcome. Teams should evaluate whether their enforcement point can stop the action before it touches the environment.
Agent-specific guardrails must be tested against destructive and disclosure paths, not generic misuse: If a control cannot stop shell deletion, secret exfiltration, or raw PII disclosure in a live runtime, it is not yet a governance boundary. The article shows why real validation has to follow the same path the agent uses to act.
For practitioners
- Enforce execution-path denial for risky agent actions Require every file read, shell command, or privileged tool call to pass through an allow-or-deny gate before execution proceeds.
- Classify prompt policy as advisory only Use context injections to guide behaviour, but do not treat prompt text as a sufficient barrier for destructive commands or secret access.
- Redact secrets before transcript persistence Scan tool results for API keys, tokens, certificates, and PII before they are stored in conversation history, while assuming the model may already have seen the raw value.
- Verify every hook actually fires in runtime Trace security hooks from registration to invocation in the shipped binary so that a defined control is not mistaken for an enforced one.
Key takeaways
- AI agents can still expose secrets, disclose PII, or run destructive commands when guardrails live only in prompts or post-processing.
- The article shows that runtime denial on the tool path is more effective than policy text or transcript scanning after the fact.
- For agent governance, the control question is whether the system can stop harmful action before execution, not whether it can explain the policy afterwards.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on AI agents misusing delegated tool access and privileges. |
| ASI02 — Tool Misuse | The core issue is harmful file and shell tool use by the agent. | |
| Recommendation — Constrain agent permissions and deny tool use that exceeds the task’s approved scope. Validate every tool call against policy before execution and block unsafe commands at the tool boundary. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The agent relies on security gates and tool calls to prove authorised action paths. |
| NHI-05 — Overprivileged NHI | The article shows the risk of agents being able to read and act beyond necessity. | |
| Recommendation — Authenticate agent action paths and reject tool execution that lacks a verified approval path. Minimise agent access to only the files and commands required for the task. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime allow-deny decisions map directly to access authorization for agent actions. |
| Recommendation — Review agent entitlements regularly and remove any permission that is not essential. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The post depends on controlling the credentials and tokens an agent can use during execution. |
| Recommendation — Manage agent credentials so secrets are issued, tracked, and revoked under strict lifecycle control. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article demonstrates secret exposure and destructive command execution as primary threat outcomes. |
| Recommendation — Map agent misuse to credential access and impact tactics, then prioritise detections for both. | ||
Key terms
- AI Agent Guardrail: A guardrail is a control boundary that limits what an AI agent can access, invoke, or change. In practice it combines identity, authorisation, approvals, monitoring, and audit so the agent's behaviour stays inside an approved task rather than drifting into broader system access.
- Tool-Path Enforcement: Tool-path enforcement means the security decision happens where the agent actually calls a tool or command. This matters because an agent can ignore advisory text, but it cannot complete a blocked action if the runtime denies the call before execution.
- Transcript Redaction: Transcript redaction removes sensitive content from stored conversation history after a tool result or message is received. It reduces persistence risk, but it does not guarantee that the model never saw the raw secret or that the secret was not already used in the current turn.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org