The Coding Agent Attack Surface Needs More Than Posture Checks

Coding agents have a misconfiguration problem. YOLO mode enabled to reduce approval friction, sandbox enforcement disabled, Model Context Protocol (MCP) servers installed from public marketplaces without security review. These are common configurations in enterprise developer environments, and remediating them is genuinely valuable work. AI Security Posture Management (AISPM) addresses exactly this class of risk, surfacing misconfigurations before they create the conditions for a successful attack.

Zenity's approach to coding agent security starts with posture management and doesn't stop there. Posture assessment tells you what an agent was configured to do at a point in time. It can't tell you what the agent did after that point, what it was manipulated into doing by injected instructions in a GitHub issue, or what sensitive data it accessed and transmitted in the five minutes after the last scan ran.

That's the gap Zenity's runtime detection layer is built to close.

What Posture Management Catches

The most common enabling conditions for coding agent attacks aren't sophisticated attack techniques. They're configuration choices developers make to reduce friction.

Permission mode governance

YOLO mode, and its equivalents across vendors: bypassPermissions in Claude Code, 'never' in Codex, 'Run Everything' in Cursor, disables the approval mechanisms that provide the last line of defense against unauthorized actions. Zenity's AISPM continuously monitors permission mode configurations across all agents in the environment, flagging permissive settings and alerting when agents are operating without the approval gates that the security policy requires.

Sandbox enforcement

Sandboxing in Claude Code is opt-in. In Codex and Cursor, the most permissive settings, danger-full-access and insecure_none, are policy-prohibited in Zenity's baseline. Zenity continuously assesses sandbox configuration against the enterprise baseline and surfaces any drift, whether from a developer changing a setting or from a configuration write that the agent itself made.

MCP server governance

Third-party MCP servers, skills, and plugins installed from public marketplaces execute with the permissions of the connected agent, run outside the sandbox, and have access to everything the agent has access to. Zenity inventories MCP server connections across the developer estate, flags unreviewed connections, and surfaces the permission scope each server inherits so security teams can apply the same review process they'd apply to any third-party software installation.

What Runtime Detection Catches

A correctly configured coding agent can still be attacked. Prompt injection happens at runtime, not at configuration time. The agent that passes every posture check can be redirected mid-session by injected instructions in a GitHub issue it reads as part of a normal task.

Zenity's stateful threat engine monitors the agent's execution trajectory in real time, flagging behavioral patterns that posture checks can't see.

Taint tracking: sensitive access to network output

Zenity detects and blocks any session in which the agent accesses a sensitive file, an .env file, an SSH key, a credential store, and subsequently attempts a network-bound action not previously observed in similar task contexts. Detection and blocking happen at the hook layer via PreToolUse, intercepting the call before it executes. The individual events are both authorized. The relationship between them is the signal.

Post-ingestion anomaly detection

Zenity flags agents that install packages, write to restricted paths, or attempt external network calls immediately following ingestion of external content, whether that's an MCP server response, a web-fetched page, or repository content. The temporal relationship between external content ingestion and subsequent anomalous action is the injection signature, and Zenity's detection engine is built to surface it even when every individual action is authorized.

Restricted path write detection

Writes to agent configuration files, CLAUDE.md, ~/.claude/settings.json, .git/hooks, and their equivalents across other coding agents, are a persistence mechanism. An injection-triggered write to these paths installs attacker instructions that survive session termination and load at the next startup. Zenity detects writes to these paths that weren't initiated by an explicit developer action and surfaces them as high-priority Issues.

Full-Lifecycle Coverage, Agentlessly Deployed

Zenity captures agent telemetry via OpenTelemetry and native hooks, normalized across Claude Code, Cursor, Codex, and other coding agents into a consistent data model. There's no endpoint sensor required and no developer friction to deploy. The instrumentation captures tool invocation sequences, MCP server interaction content, file system access correlated against task context, and session-level behavioral records that assemble individual events into a complete picture of what the agent did.

The posture layer and the runtime layer together answer the two questions a complete coding agent security program requires: 'Was this agent correctly configured?' and 'Did it behave consistently with its declared purpose?'

Want the full threat model, detection patterns, and governance framework? Download The Ultimate Guide to Securing Coding Agents → Get the eBook