By NHI Mgmt Group Editorial TeamDomain: Agentic AI & NHIsSource: UnosecurPublished July 16, 2026

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.


At a glance

What this is: Kimi K3’s launch showed that the first security problem was agent identity and tool authority, not model jailbreak success.

Why it matters: IAM, NHI, and agentic AI teams need to separate model behaviour from execution authority, because the real exposure sits in credentials, tool permissions, and session controls.

👉 Read Unosecur's analysis of Kimi K3, Kimi Code, and agent identity risk


Context

Agentic AI systems create a governance problem when the model, the tool harness, and the underlying credentials all influence what happens next. In this case, the primary issue is not whether Kimi K3 can be jailbroken, but whether an agent with MCP access, session approval, and backend credentials can turn a wrong decision into an authorised action. That is an identity and access management problem as much as a model safety problem.

The article points to a familiar failure pattern in non-human identity control: authority is split across the model, the harness, and the server, but enforcement is uneven. When permission rules stop at tool names, or when approval is expanded to a whole session, the system starts behaving like standing privilege with a conversational front end. That is why the topic belongs in agentic AI and NHI governance rather than only in prompt security.


Key questions

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. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do MCP-connected agents create harder access-control problems than chatbots?

A: Because they can turn model output into real actions. A chatbot can be wrong without consequence, but an MCP-connected agent can write files, call APIs, or trigger workflows. That means tool identity, caller identity, and argument validation all matter, not just the quality of the model’s response.

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. That creates a false sense of control because the agent still has enough authority to act. Parameter-level evaluation is necessary whenever the same tool can be used safely or dangerously.

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.


Technical breakdown

Static, behavioral, and dynamic identity layers in agentic systems

Agent identity in an MCP-connected system is not a single control point. The static layer is the credential or registration used to authenticate the client or server, the behavioral layer is the observable sequence of tool calls, and the dynamic layer is the live context that shapes what the model decides next. Security breaks when the dynamic layer can steer the tool call while the static layer still authorises it. That means a malicious prompt, untrusted repository content, or ambiguous user intent can still produce a valid external action if enforcement does not sit outside the model.

Practical implication: Separate model interpretation from execution authorisation so that tool calls are validated by server identity, arguments, and context before action.

MCP permission matching and tool-call abuse

The article highlights a common weak point in agent harnesses: permission logic that matches the tool name but not the parameters or resulting effect. If a rule approves mcp__github__* or a similar wildcard, the system may treat read and write actions as equivalent when they are not. Session approval can then turn a single decision into repeated access, while auto mode removes the review loop entirely. This is not jailbreak behaviour. It is an authorisation design problem in the non-human identity layer that governs the agent’s reach.

Practical implication: Require argument-level authorisation and session-scoped expiry for every tool call, not just a one-time approval by tool name.

Harness bugs versus model safety failures

The confirmed launch-week bugs in Kimi Code were an authentication bypass and a path traversal issue, which means the exposed control plane sat in the harness, not the model. That distinction matters because model refusals do not protect an endpoint that accepts unauthenticated requests or follows symlinks outside the workspace. In identity terms, the harness became the real policy enforcement surface, and when that surface fails, the model’s safety layer is irrelevant to the breach path.

Practical implication: Audit the harness, MCP server, and workspace boundary as primary enforcement points, because model-level safety cannot compensate for broken transport or filesystem controls.


Threat narrative

Attacker objective: The attacker wants to turn a trusted agent session into a higher-authority execution path that reaches tools, data, or infrastructure without proper review.

  1. Entry occurs when a compromised or misconfigured agent harness, MCP server, or exposed tool interface accepts traffic it should not, including unauthenticated access through a bypass or a malicious path into the session workspace.
  2. Escalation occurs when the model’s conversational output or a session approval state is converted into tool execution, allowing the agent to exercise privileges that were broader than the original request implied.
  3. Impact occurs when the agent can reach repositories, cloud resources, or enterprise applications and turn a mistaken or manipulated decision into authorised external action, data access, or destructive change.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

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.

Tool-name matching is a weak substitute for non-human authorisation. A permission rule that approves a tool family without evaluating arguments, provenance, or effect creates the same kind of ambiguity that IAM teams have spent years removing from human access. That is especially dangerous in agentic systems because a benign prompt can still produce a consequential call. The implication is that tool identity alone does not define intent, and intent alone does not define safety.

Standing privilege reappears when session approval becomes a blanket policy. The article’s session approval and auto mode examples show how temporary convenience can harden into persistent reach across multiple calls. In NHI terms, this is privilege persistence under a conversational workflow. Practitioners should recognise that session-wide consent behaves like standing access unless the approval boundary is narrowly enforced.

Agentic AI now exposes a governance assumption that was designed for human-paced review. Access review processes were built on the assumption that privilege persists long enough to be observed, logged, and certified. That assumption fails when an agent can acquire and use access within a single session, before a human reviewer ever sees a stable state. The implication is that review cadences alone cannot govern autonomous or semi-autonomous execution paths.

Runtime identity needs to be enforced outside the agent because model context is not a trust boundary. The article’s control examples show why provenance, server identity, and per-call enforcement matter more than the model’s own interpretation of intent. In practice, this means the security programme must assume the agent will make the wrong decision at some point. The right question is what identity controls still hold when it does.

From our research:

  • 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.
  • That confidence gap is a signal to move from model-centric discussions to control-point design, as explored in Ultimate Guide to NHIs.

What this signals

Agentic AI governance will increasingly converge with NHI control design. The practical programme shift is away from trusting the model and toward controlling the delegation chain, the tool surface, and the session boundary. With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the market is already moving toward runtime enforcement rather than static review alone.

Tool approval without provenance will become a measurable governance defect. Teams that cannot prove who authorised a call, what parameters were sent, and which server executed it will struggle to defend agent actions during an incident. That is why structured provenance and per-call policy need to become baseline expectations, not optional hardening.

Session-scoped consent is the new standing privilege problem. Any approval mode that outlives the immediate task should be treated as a governance exception and measured as such. For practitioners, the near-term signal to watch is whether agent platforms can enforce expiry, scope, and context without relying on the user to stay vigilant.


For practitioners

  • 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. Validate server identity, tool schema, arguments, and provenance before allowing any action.
  • Remove wildcard tool approvals Replace broad tool-family rules with per-call authorisation that distinguishes read, write, and destructive operations. If parameters are excluded from matching, treat that as a control gap, not a usable safeguard.
  • Limit session approval to a true task window Expire approvals automatically and avoid session-wide consent that survives beyond the immediate request. Review any mode that allows repeated calls without human interaction, because it behaves like standing privilege.
  • Audit the harness for transport and filesystem failure modes Test the agent wrapper for authentication bypass, path traversal, symlink escape, and malformed request handling. Those failures sit above the model and can expose every tool the agent can reach.
  • Record structured provenance for every agent action Preserve the caller identity, tool name, arguments, and repository or workspace context as machine-readable metadata. Without that record, incident response cannot separate model behaviour from execution abuse.

Key takeaways

  • The article shows that agent security failures often begin in the harness, where authentication, permissions, and execution boundaries are enforced.
  • Model jailbreak claims matter less than documented control failures such as authentication bypass, path traversal, and session-wide approval.
  • Practitioners should redesign agent governance around per-call authorisation, structured provenance, and short-lived delegation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10The article centers on agent jailbreaks, tool misuse, and runtime authority.
OWASP Non-Human Identity Top 10NHI-03The post highlights credential, approval, and session governance failures for non-human identities.
NIST CSF 2.0PR.AC-4The issue is unauthorized or overbroad access to tools and resources.
NIST Zero Trust (SP 800-207)The article argues for enforcement outside the model and continuous verification of access.
NIST SP 800-53 Rev 5IA-5Credential and authenticator governance is central to the exposed harness and backend access.

Review NHI credentials, session approval, and tool access against NHI-03 and restrict standing access.


Key terms

  • Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
  • MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
  • Session Approval: A temporary consent state that allows an agent to repeat a class of actions without asking again. In an agentic context, this can behave like standing privilege if the approval window is too broad or the rules do not inspect parameters and context.
  • Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.

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

👉 The full Unosecur post covers the Kimi Code control failures, MCP permission gaps, and enforcement model in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org