White Paper
Runtime Security for Coding Agents
An easy guide to securing Cursor, Claude Code, and OpenClaw with two-plane runtime verification.
Executive Summary
Coding agents are becoming part of everyday software delivery. They read code, run shell commands, access tokens, install packages, and interact with external services. That makes them powerful productivity tools, but it also makes them high-impact security subjects on developer workstations, build hosts, and self-hosted agent servers.
This white paper explains a simpler model for securing them. Hardening and setup still matter, but they are only the first layer. The missing layer is runtime verification: compare what the agent says it is doing with what the machine actually does. When the Model Context Protocol (MCP) is available, that intent can be surfaced more directly.
The Coding-Agent Risk Landscape
Modern agent workflows collapse several sensitive capabilities into one loop: read repositories, call tools, modify files, use network access, and touch credentials. Common risk patterns include:
- Hidden instructions in issues, docs, or chat that change future tool calls
- Malicious MCP servers, plugins, or dependencies that reshape agent behavior
- Exfiltration of tokens, SSH keys, CI secrets, or source code
- Posture drift on the host while the agent keeps working
Because agents operate with valid local context and legitimate tools, many failures do not look like classic malware at first. The system may appear to be working normally while risk quietly increases.
This is exactly why coding-agent security needs better runtime visibility, not just stronger setup checklists.
Why Traditional Controls Fall Short
Supply-Chain and Setup Controls
Signed packages, dependency review, sandbox configuration, local binding, PSK-protected MCP endpoints, and tool scoping are important. They reduce obvious exposure before the agent starts working.
But once an agent is running, those controls do not fully explain whether its observed behavior still matches the declared task. Setup quality reduces risk. It does not eliminate runtime drift.
Identity and Login-Time Trust
Identity systems do a good job at authenticating the user and establishing a trusted session. Device checks at sign-in can also improve the starting point.
The weakness is persistence. A workstation or server can change after login, and agent work can continue through tokens, SSH keys, or already-approved tooling. Login-time trust is not the same as continuous runtime trust.
Sandboxes, Tool Scopes, and Policy Hardening
Restricting tools and limiting privileges are essential for safe deployment. Narrow scopes reduce blast radius and make abuse harder.
Yet even a well-scoped agent can still perform undeclared behavior inside its allowed surface: unexpected egress, suspicious file access, risky package installation, or posture degradation on the host. Policy hardening helps, but it does not create runtime truth on its own.
Network and Perimeter Controls
VPNs, overlays, and allow-lists still matter for managing access to internal services and build infrastructure. They can make the environment harder to reach from the outside.
What they do not provide is process-aware runtime understanding. A network control can tell you that traffic exists. It usually cannot tell you whether the traffic matches the agent's declared task, or whether it came from a trusted agent process on a still-compliant host.
The Runtime Security Gap
The gap appears after the basic controls are in place. The host may be patched, the MCP endpoint may be bound locally, and the agent may be scoped correctly, yet a mismatch can still emerge during execution.
- The task is read-only, but the process tree starts making undeclared outbound connections
- The agent claims to edit one file, but the host posture changes at the same time
- A plugin or tool introduces behavior that was not part of the original intent
- A workstation or runner loses compliance while the agent keeps operating
- The setup still looks correct, but runtime behavior no longer matches the declared task
EDAMAME Architecture Overview
EDAMAME applies this model across workstations, CI/CD, and self-hosted agent hosts with a product split that stays simple for users:
- EDAMAME Security: workstation trust anchor for developers and local devices
- EDAMAME Posture: CLI and host control surface for runners, servers, and agent hosts
- Integration packages: Cursor, Claude Code, and OpenClaw as named runtime surfaces
- Divergence engine: compares declared intent with process, network, and posture telemetry
- Hub and Portal: central visibility, account management, and fleet coordination
This is not a second interface bolted onto the SDLC. It is a way to bring runtime verification into places where developers and agents already work.
Applying the Model on Workstations and Agent Hosts
The same core model works across very different environments. On developer machines, the key problem is securing both the workstation and the coding assistant on it. On self-hosted infrastructure, the key problem is hardening the host while watching for runtime divergence.
With EDAMAME:
- Workstations can be monitored for posture drift while Cursor or Claude Code runs locally
- Self-hosted servers and VMs can be hardened with EDAMAME Posture before agents are allowed to operate
- MCP-aware integrations can publish intent context that the security observer can compare with live telemetry
The result is a more practical control loop: secure the surface first, then verify behavior continuously while the agent works.
Real-World Attack Scenarios and How EDAMAME Responds
Scenario 1: Hidden Instruction or Prompt Injection
Without runtime correlation: the agent keeps using allowed tools, but future actions drift away from the original task.
With EDAMAME: unexpected traffic, file access, or process activity can be compared against the declared workflow and surfaced as a mismatch.
Scenario 2: Compromised Workstation or Agent Host
Without continuous posture checks: the agent keeps operating on a device or server whose security state has degraded.
With EDAMAME: posture changes become part of the runtime picture, so risky drift can trigger escalation or access changes before trust silently persists.
Scenario 3: Tool or Plugin Poisoning
Without an independent observer: a malicious tool can stay inside the allowed tool surface while steering the agent toward harmful behavior.
With EDAMAME: the question is not only which tool was available, but whether observed behavior remained consistent with the task and the host's expected state.
These examples do not promise perfect prevention. They show why runtime verification creates a stronger early-warning layer than setup controls alone.
From On-Prem Thinking to Modern Agent Security
Traditional secure environments relied on strong boundaries, fixed infrastructure, and tightly controlled access paths. Modern agentic development is different: remote work, cloud services, dynamic IPs, contractor access, CI/CD automation, and agent tooling all widen the operating surface.
- Keep strong security expectations without forcing everything back into admin-down workflows
- Apply one trust model across developer laptops, build hosts, and agent servers
- Support hybrid reality: local development, SaaS code hosting, and self-hosted agent environments
- Carry the same runtime-verification principles across multiple surfaces
Governance, Audit Readiness, and Operational Confidence
Leaders need more than a promise that an agent was configured correctly. They need evidence about what was allowed, what was observed, and what happened when trust changed. That is useful for security operations, internal reviews, and formal governance work alike.
- Continuous visibility into posture and runtime behavior
- Clear evidence trail for alerts, policy actions, and operator review
- Dynamic enforcement when trust degrades, not just periodic checks
This matters for audit readiness, but it matters even more for day-to-day decision-making. Better evidence reduces both blind trust and unnecessary panic.
Implementation and Deployment Overview
- Start with EDAMAME Security on developer workstations
- Use EDAMAME Posture on CI/CD runners, servers, and self-hosted agent hosts
- Connect Cursor, Claude Code, or OpenClaw through the relevant integration path
- Define posture and runtime policies that match the environment
- Use Hub or operational surfaces to review alerts, posture state, and actions
- Expand from one surface to another without changing the underlying model
The important point is simplicity: the runtime story should stay understandable even as the deployment surface grows.
The Strategic Advantage: Control + Speed + Trust
Organizations do not want to choose between developer speed and stronger security. They want a model that respects modern workflows while giving security teams better runtime evidence.
- Productivity from developer-first and agent-first workflows
- More trust because verification continues after initial setup
- Lower friction than heavy admin-down or proxy-heavy approaches
- One security language across devices, runners, and coding agents
In short: runtime verification lets teams delegate more safely because trust is checked against reality, not assumed.
Conclusion and Call to Action
Coding agents have become part of the software delivery surface. They deserve a security model that reflects what they actually do: read, execute, modify, connect, and decide at runtime.
The practical path forward is not to discard hardening, identity, or policy controls. It is to add the missing layer: compare declared intent with observed system behavior, then act when they diverge.
With EDAMAME, teams can secure the workstation, secure the host, and add runtime verification across Cursor, Claude Code, and OpenClaw from the same broader trust model.
