Notifications
Clear all
Topic starter
19/08/2026 3:38 pm
TL;DR: Agentic AI security now spans identity, memory, tool access, and runtime enforcement, because agents can plan, call APIs, write data, and persist instructions across workflows without constant oversight, according to Cycode. The governance problem is that access review models assume stable, reviewable behaviour, but autonomous action can create privilege use and leakage before any human sees it.
NHIMG editorial — based on content published by Cycode: What Is Agentic AI Security?
By the numbers:
- The average enterprise has around 37 deployed agents in the environment, and this number continues to increase as each engineering team builds its own automation.
- Only 22% of teams treat agents as independent identities, breaking audit trails and accountability.
- Only 24.4% of organizations have full visibility into agent-to-agent communication.
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do NHIs complicate zero trust and least privilege efforts?
A: NHIs complicate zero trust because they are numerous, persistent, and often tightly integrated into applications and pipelines.
Q: What breaks when AI agents share memory and tool access across sessions?
A: Shared memory and tool access can preserve bad instructions, permissions, or context long after the original interaction.
Practitioner guidance
- Assign distinct identities to every agent Issue each agent its own attributable identity, separate from human tokens and shared service accounts.
- Separate read, write, and execute paths Do not let the same agent entitlement cover data retrieval, record modification, and downstream action.
- Instrument memory as a governed control surface Inventory conversation history, vector stores, and persistent memory as assets that can affect future decisions.
What's in the full article
Cycode's full article covers the operational detail this post intentionally leaves for the source:
- Specific breakdowns of agentic development security controls across the SDLC and runtime.
- Cycode's explanation of how its Maestro engine and AI Exploitability agent triage and remediate findings.
- Examples of AI guardrails, AIBOM governance, and MCP enforcement in development workflows.
- Implementation detail for blocking risky prompts, secret leaks, and unauthorized tool calls before release.
👉 Read Cycode's analysis of what agentic AI security requires →
Agentic AI security: are your controls keeping up?
Explore further
19/08/2026 4:18 pm
Agentic AI security is an identity governance problem before it is an application security problem. The article correctly shows that the risk surface sits across identity, permissioning, memory, and runtime execution, not only model output. That matters because the enterprise failure mode is not a harmful sentence. It is a trusted non-human actor with enough access to change records, move data, or trigger workflows. Practitioners should read this as a governance shift, not a tooling add-on.
A few things that frame the scale:
- Only 22% of teams treat agents as independent identities, breaking audit trails and accountability, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: Agentic AI security exposes identity, tool and memory risks
