Coding Agents Now Ship With Their Own Runtime Guards: What the DeepKeep and Arcjet Launches Mean for Your Evidence Pack
In the first two weeks of October 2026, DeepKeep and Arcjet both launched runtime security aimed at coding agents such as Cursor and Claude Code. The pitch is visibility and policy enforcement on the developer machine. Here is what those launches can realistically give a SOC 2 or ISO 27001 audit, what they cannot prove on their own, and the questions to ask before you rely on one.
On 1 October 2026 DeepKeep announced AI Lens for Developers, an extension of its AI usage control and runtime protection modules aimed at coding agents that write, modify and execute code on a developer machine. The company pitches policy enforcement, audit visibility and runtime security over tools such as Cursor and Claude Code, and trade coverage described it as flagging possible data leaks from agent sessions and routing destructive commands for approval. A week later, on 8 October, Arcjet introduced Arcjet Runtime Security for Coding Agents, which extends its existing agent runtime platform to the coding tools developers already use. Its stated aims are to discover coding agents on endpoints, enforce one policy across developer tools, and keep a record of agent actions and the policy decisions made about them.
The gap these vendors are targeting is real, and most security teams will recognise it. A lot of organisations have approved coding agents on paper. There is a vendor review, a line in the acceptable use policy and perhaps a note in the Windsurf vendor register or a Cursor security review. What is usually missing is any view of what the agent actually did on a given Tuesday: which shell commands it ran, which files it read, which MCP tools it called and whether a token ended up in a prompt. The audit trail also tends to name the developer rather than the agent, because the agent runs inside the developer session and inherits that session access. Your controls were designed around people, and an agent is a new kind of actor that happens to use a person login.
A runtime guard is only as useful as the record it leaves behind, so start with the evidence rather than the dashboard. For each agent action you should be able to see the agent identity, the developer and machine, the repository, the tool or command invoked, the policy that matched and the decision taken. Denied actions matter as much as allowed ones, because a control that never fires is indistinguishable from a control that is not there. Ask whether logs can be exported with timestamps and policy versions, whether they can be streamed to your SIEM, and how long they are retained. A screenshot of a green dashboard is not evidence. An exported log line showing a blocked production secret read, under a named policy, from a specific managed laptop, is.
Map the output to the frameworks you are already audited against. SOC 2 common criteria on logical access, system monitoring and change management (CC6, CC7 and CC8) are the closest fit, because a runtime policy is a monitoring control and an approval gate on destructive commands is a change control. In ISO 27001:2022 the relevant Annex A controls are 8.2 on privileged access rights, 8.15 on logging and 8.16 on monitoring activities. For ISO 42001, the coding agent belongs in the AI system inventory with an owner and a stated purpose, and the runtime policy is part of the operational controls that keep it inside its intended use. The same register should feed the access reviews and offboarding tasks you already run for staff, so that a departing engineer also loses the agent credentials they were using.
Be clear about what a runtime product cannot prove by itself. A vendor that blocks a command shows that the rule fired, not that the rule is right. Default policies written by the vendor are not your policy, and you need to own the rules for production credentials, customer data paths and package installation. Coverage is the other weak point. An agent running on a personal laptop, in a browser tab, on a contractor machine or under a personal account sits outside the endpoint agent entirely. Measure coverage by comparing the endpoint inventory from your device management tool with the list of machines where coding agents are actually installed, and report the gap rather than the headline number. If coverage is 80 percent, say so in the evidence pack.
Treat the runtime vendor as a sub-processor as well as a control. The product sees source code, prompts, file paths and sometimes secrets in transit, so it needs a data processing agreement, a stated data location and retention terms, and an entry in your vendor register alongside the coding agent itself. Check whether the product stores full prompt content or only metadata, because that choice changes your privacy impact assessment and what you can safely keep in logs. This is the same discipline that applies to any AI vendor, and it is easy to skip because the runtime tool feels like part of your security stack rather than another supplier.
For the next four weeks, a sensible sequence looks like this. First, inventory every coding agent in use across the organisation, including Cursor, Claude Code, Windsurf or Devin Desktop, Cline and GitHub Copilot. Second, name an owner and write the policy in plain terms, with the list of production systems, credentials and destructive commands that need approval. Third, run the product in observe-only mode for two weeks to measure false positives before enforcing anything, and record what the team learned. Fourth, route approvals to a named person with a response time, because an approval queue nobody watches becomes a bottleneck that developers route around. Finally, test one blocked action end to end, keep the log export and the approval record, and file them with the SOC 2 or ISO 27001 evidence for the period.
Our view is that the category is useful and still early. The buying test we would use is simple: could you hand an auditor a single log entry that shows an agent was stopped from reading a production secret, on a specific date, under a specific policy version, from a specific managed machine, and explain who approved the rule? If the answer is no, you have bought a dashboard rather than a control. Runtime guards for coding agents are worth having, but they do not replace the agent register, the vendor review or the access model underneath them. They make those things measurable, which is the part auditors ask about most.
Editorial note: AES Tech reviews are independent. Some outbound links are affiliate links and are marked sponsored; they never change our rankings. See our disclosure.
Get the next post by email
One short email when something worth knowing ships. No spam, unsubscribe anytime.
Comments
Moderation policyLoading comments...
Add a comment
Corrections and first-hand experience are the most useful things you can leave. Comments are screened automatically and reviewed by a human; see the moderation policy.