Notifications
Clear all
Topic starter
09/07/2026 10:03 am
TL;DR: AI coding agents are moving beyond developer workflows into broader knowledge work, with MCP servers, IDE extensions, and skill configurations creating new exposure points for command execution, data access, and supply chain dependence, according to Knostic. The governance gap is now less about whether these tools are useful and more about whether organisations can discover, monitor, and contain them before they touch production systems.
NHIMG editorial — based on content published by Knostic: Open Source Tools for Security Teams and the OpenClaw agent control gap
Questions worth separating out
Q: How should security teams govern AI coding agents that can access tools and services?
A: Security teams should treat AI coding agents as governed software entities with explicit tool permissions, lifecycle logging, and named ownership.
Q: What breaks when AI agents are deployed without discovery controls?
A: Without discovery controls, organisations cannot tell whether an agent is approved, duplicated, or hiding in an unmanaged endpoint path.
Q: How do security teams know whether agent telemetry is actually working?
A: Telemetry is working when it captures tool calls, lifecycle events, and message traces in a way that supports investigation and correlation.
Practitioner guidance
- Inventory all agent entry points Scan managed devices and build environments for CLI binaries, app bundles, gateway services, config files, and container artifacts associated with coding agents and their extensions.
- Govern MCP and extension permissions Review every MCP server definition, IDE extension, rule file, and skill configuration as a policy object with explicit approval, scope, and ownership.
- Require behavioural telemetry for agents Collect tool-call logs, message events, and lifecycle traces with sensitive-data redaction and tamper-resistant storage so security teams can investigate agent actions later.
What's in the full article
Knostic's full research covers the operational detail this post intentionally leaves for the source:
- OpenClaw-specific detection logic for managed devices, including binaries, bundles, gateway services, and Docker artifacts.
- Telemetry design details for tool calls, lifecycle events, message events, and redaction in JSONL output.
- Implementation notes for forwarding logs into SIEM workflows and existing response playbooks.
- Deployment guidance for MDM platforms such as Intune, Jamf, JumpCloud, Kandji, and Workspace ONE.
👉 Read Knostic's analysis of OpenClaw detection and telemetry for AI coding agents →
AI coding agents and MCP security: what practitioners need now?
Explore further
09/07/2026 10:04 am
AI coding agents are becoming a supply chain governance problem before they become a platform standard. The article shows that adoption is already happening through individual developer and knowledge-worker behaviour, which is exactly how shadow tooling becomes operational. Once these agents can reach code, commands, and external services, security teams need policy at the tool boundary, not just at user sign-in. Practitioner conclusion: inventory and govern agent entry points before usage normalises.
A question worth separating out:
Q: Who should own risk when an AI coding agent is used across teams?
A: Ownership should sit with the team that approves the agent’s deployment and defines its scope, because the risk is created by runtime access and inherited trust. Where agents touch code, secrets, or connected services, ownership should also include IAM, endpoint security, and application security stakeholders.
👉 Read our full editorial: AI coding agents are creating a new supply chain control gap
