Notifications
Clear all
Topic starter
25/06/2026 1:28 am
TL;DR: Claude agents can move from prompt to tool use, code change, and business action fast enough that logs alone miss setup-layer risk, runtime abuse, and downstream impact, according to Zenity. Identity and access programmes now need lifecycle visibility, posture checks, and inline enforcement for agent behaviour, not just after-the-fact review.
NHIMG editorial — based on content published by Zenity: Claude's Agents Are Already Running Across Your Enterprise. Now Security Teams Can Catch Up
Questions worth separating out
Q: How should security teams govern Claude agents that can change code and data?
A: They should treat Claude as an identity-bearing execution surface, not just an application.
Q: Why do agent controls need to start before the first prompt?
A: Because hostile behaviour can be introduced in the setup layer through MCP servers, plugins, skills, hooks, or misconfiguration.
Q: What do security teams get wrong about agent session logs?
A: They often assume logs are enough to explain risk.
Practitioner guidance
- Inventory all Claude-connected extensions Catalogue MCP servers, skills, plugins, hooks, and local configuration scopes before allowing enterprise rollout.
- Correlate agent sessions to downstream artefacts Link Claude activity to pull requests, commits, file changes, and business actions so investigators can reconstruct intent and sequence.
- Block risky execution before repository impact Apply inline controls that stop destructive actions, credential exposure, or suspicious command activity before the agent reaches source code, secrets stores, or production systems.
What's in the full article
Zenity's full article covers the operational detail this post intentionally leaves for the source:
- How Zenity correlates Claude Code sessions with pull requests and commits for investigations
- How the platform evaluates MCP servers, skills, plugins, and configuration posture before sessions begin
- How inline prevention works when Claude attempts destructive actions, credential exposure, or suspicious commands
- How security, compliance, and platform engineering teams can divide responsibilities across one control plane
👉 Read Zenity's analysis of Claude agent lifecycle security and runtime controls →
Claude agent lifecycle security: are your controls keeping up?
Explore further
25/06/2026 10:55 am
Claude agent security is now a full lifecycle governance problem, not a logging problem. The article shows that context, extension posture, runtime behaviour, and downstream artefacts all matter at once. That means security teams need to govern the agent path from configuration to execution, not just review the output after the fact. The practitioner conclusion is clear: agent visibility without lifecycle control is incomplete governance.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, and a quarter encountered multiple attacks.
A question worth separating out:
Q: How do organisations decide whether an AI agent action was acceptable?
A: They should evaluate the full session against the stated task, the approved tool set, and the downstream effect. If the agent’s cumulative actions exceed the intended work or reach sensitive systems without clear policy basis, the action was not acceptable even if individual steps looked routine in isolation.
👉 Read our full editorial: Claude agent governance now needs lifecycle visibility and runtime control
