Notifications
Clear all
Topic starter
02/08/2026 11:47 am
TL;DR: A market now splits between governance-first visibility and active testing plus runtime enforcement, while highlighting gaps in SaaS-centric coverage, MCP security, and red teaming, according to Akto. The core issue is that AI agent identity, permissions, and tool use require controls built for runtime behaviour, not just posture review.
NHIMG editorial — based on content published by Akto: Zenity Security features, architecture, limitations, and Akto comparison
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 AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously.
Q: What breaks when agent security stops at discovery and posture review?
A: Discovery and posture review can show that an agent exists and appears compliant, but they do not prove the agent behaves safely under real conditions.
Practitioner guidance
- Map every agent to an owner, tool chain, and data boundary Build an inventory that includes SaaS-managed agents, homegrown agents, and endpoint-based assistants.
- Test agent behaviour under adversarial conditions Use red teaming or equivalent probe libraries to validate prompt injection resistance, tool misuse handling, permission escalation resistance, and data exfiltration paths before production rollout.
- Control the MCP tool surface directly Review MCP server definitions, tool permissions, and protocol-level access paths separately from model access.
What's in the full article
Akto's full blog post covers the operational detail this analysis intentionally leaves for the source:
- A side-by-side feature breakdown of Zenity Observe, Govern, and Defend across SaaS, cloud, and endpoint environments
- Specific limitations around homegrown agents, LangChain-style deployments, and MCP tool execution coverage
- Detailed comparison points between governance-first and attack-first approaches for agentic AI security
- Product-level descriptions of Akto Atlas and Akto Argus for teams evaluating discovery, red teaming, and runtime enforcement
👉 Read Akto's comparison of Zenity and Akto for AI agent security →
AI agent security platforms: are discovery and runtime controls enough?
Explore further
02/08/2026 12:57 pm
Governance-first AI agent security is necessary but incomplete. Discovery and policy control matter, especially when enterprises cannot even name all the agents running in their environment. But governance does not equal containment if the platform stops at posture and inventory. The central weakness is the assumption that visibility over an agent is enough to control its behaviour. Practitioners need to treat governance as the baseline, not the finish line.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Our research also shows that 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: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.
👉 Read our full editorial: AI agent governance still breaks at discovery, runtime, and scope
