Notifications
Clear all
Topic starter
11/08/2026 3:17 pm
TL;DR: Moonshot AI’s Kimi K3 launch exposed that agent security failures start in the harness, not the jailbreak, as documented authentication bypass, path traversal, MCP permission gaps, and auto-approval behaviours created direct action paths, according to Unosecur. The security question is who controls tool authority when model intent can become an authorised external action.
NHIMG editorial — based on content published by Unosecur: The Kimi K3 launch proved the identity problem before anyone tried to jailbreak it
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 MCP-connected agents create harder access-control problems than chatbots?
A: Because they can turn model output into real actions.
Q: What breaks when tool permissions match names but not parameters?
A: A permission rule can approve a harmless-looking tool while the parameters request a destructive or sensitive action.
Practitioner guidance
- Separate authorisation from model output Place enforcement at the MCP gateway, server, or proxy layer so the model cannot directly convert interpreted intent into execution.
- Remove wildcard tool approvals Replace broad tool-family rules with per-call authorisation that distinguishes read, write, and destructive operations.
- Limit session approval to a true task window Expire approvals automatically and avoid session-wide consent that survives beyond the immediate request.
What's in the full article
Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of the documented Kimi Code security bugs and how they surfaced in the harness
- Concrete examples of MCP permission behaviour, including session approval and tool-name matching
- Detailed walkthrough of the gateway enforcement model for identity, intent analysis, and JIT access
- Operational comparison of tool execution paths across repositories, cloud systems, and enterprise applications
👉 Read Unosecur's analysis of Kimi K3, Kimi Code, and agent identity risk →
Kimi K3 and MCP: what broke first in agent identity controls?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:29 pm
Agent identity is no longer a model safety issue once tool execution is live. The article shows that the decisive control boundary sits between the agent’s decision and the external action, not inside the model’s refusal layer. When MCP servers, session approval, and backend credentials all participate in one flow, identity governance has to treat the harness as the enforcement point. The practical conclusion is that model behaviour and execution authority must be governed separately.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- 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.
A question worth separating out:
Q: Who is accountable when an AI agent uses delegated access incorrectly?
A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.
👉 Read our full editorial: Kimi K3 exposed the agent identity problem before jailbreaks
