Notifications
Clear all
Topic starter
09/07/2026 12:02 pm
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.
NHIMG editorial — based on content published by Knostic: Why We Built openclaw-shield: Securing AI Agents from Themselves
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams stop AI agents from exposing secrets or running unsafe commands?
A: Put enforcement in the tool path, not only in the prompt.
Q: Why do prompt-based guardrails fail against AI agent misuse?
A: Prompt-based guardrails are advisory, so they can shape behaviour but not reliably block a direct command or tool call.
Q: What do security teams get wrong about scanning AI outputs for secrets?
A: They often treat post-processing redaction as if it were prevention.
Practitioner guidance
- Treat agent tools as privileged identities Inventory every shell command, file-read path, and external tool available to the agent, then classify each one by the data it can touch and the damage it can cause.
- Move enforcement into the execution path Require an explicit allow-or-deny decision before destructive commands or sensitive file access can proceed.
- Redact before persistence and, where possible, before model use Scan tool outputs for secrets and PII as early as the architecture allows, then prevent raw values from reaching the transcript, logs, or the next model turn.
What's in the full article
Knostic's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact OpenClaw hook chain and which hooks are registered but not actually invoked in the published runtime.
- The plugin-level implementation pattern for the security gate tool that turns policy into a runtime allow-or-deny decision.
- The observed behaviour of destructive command blocking, PII handling, and secret redaction in live tests.
- The compatibility limitations tied to the current OpenClaw version and why runtime verification mattered.
👉 Read Knostic's post on openclaw-shield and AI agent guardrails →
AI agent guardrails and the governance gaps teams are missing?
Explore further
09/07/2026 12:03 pm
Prompt policy is not a control boundary for AI agents: This article confirms that text injected into the model context cannot be treated as enforcement when the same agent can still execute commands or read files. Policy copy in the prompt may influence behaviour, but the decision boundary remains in the tool chain. For practitioners, that means governance must move from guidance to runtime control.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- A separate finding shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is why delegated access remains a control gap rather than a convenience feature.
A question worth separating out:
Q: Who is accountable when an AI agent leaks data or deletes files?
A: Accountability sits with the team that granted the agent its access, defined its tool permissions, and failed to enforce runtime controls. For agentic systems, ownership cannot be delegated to the model itself. The responsible programme is the one that allows the agent to act, not the one that merely observes the outcome.
👉 Read our full editorial: openclaw-shield shows where AI agent guardrails fail
