You hired a brilliant coding agent. Who supervises it?
A developer asks a coding agent to fix a bug. The agent reads local files, changes code, runs a shell command, and calls a connected tool to gather more context. One request, several actions, and plenty of chances for sensitive data to end up somewhere it should not.
That is the appeal of coding agents: they can do more of the work. It is also the security challenge. An assistant that suggests a line of code presents a different risk from an agent that can act on a developer’s machine.
For CISOs, knowing which AI tools developers use is only the starting point. The next questions are harder: What are those tools reading? What are they sending? Which commands are they running? And can someone stop a risky action before it happens?
DeepKeep’s AI Lens for Developers brings visibility, policy enforcement, and runtime protection into these workflows. It is the first extension of AI Lens into coding agents, with controls built for how developers and their agents work.
An approved tool can still take a risky action
Approving a coding agent does not make every action it takes safe. A legitimate task can involve sensitive files, credentials, internal code, and tools connected to other systems. The developer may have permission to access all of them. That does not mean an agent should use or share everything it finds.
Consider a routine debugging task. An agent reads a configuration file to understand why a service will not connect. That file may also contain a password or access token. The security concern now extends beyond what the developer typed into the prompt to what the agent picked up along the way.
The same issue applies to Model Context Protocol (MCP) tools, which let agents interact with other tools and data sources. A request to a tool may contain sensitive information. Its response may introduce more.
A list of approved AI tools cannot answer these questions on its own. “We approved it” is a procurement milestone, not a runtime security control.
Follow the work beyond the prompt
AI Lens for Developers uses existing hooks within coding agents to inspect activity before and after actions run. These hooks provide checkpoints around prompts, shell commands, file reads, and MCP tool calls, routing activity to DeepKeep for an allow, block, or audit decision.
This gives security teams visibility into the steps behind a developer’s request. A prompt may look harmless while the files and tool responses involved contain information that needs protection.
AI Lens can inspect prompts and responses, including content accessed through file reads and MCP tools, for credentials, tokens, and passwords. It also supports controls for personally identifiable information (PII), alongside custom key-phrase detection to flag sensitive code sections or internal repositories by name.
The aim is to apply policy as the work happens, wherever sensitive content enters the agent’s workflow.
Put controls where mistakes become actions
Data exposure is one part of the problem. Coding agents can also generate insecure code or propose commands with consequences that extend well beyond the task at hand.
AI Lens can flag insecure code patterns in agent output, such as a function missing authentication. It can also flag destructive shell commands and send them to the developer for approval before they run. That keeps a familiar human checkpoint in place as agents take on more of the execution.
Developer approval and policy enforcement serve different purposes. Approval asks the developer to review a potentially destructive action. A policy block enforces a rule set by the organization.
When AI Lens blocks an action, it provides the reason behind the block. Developers can understand what triggered the decision and adjust their request, rather than being left to guess why the workflow stopped. Security controls are easier to work with when they explain themselves. A mysterious “computer says no” has never been much of a productivity feature.
Central policy, clear accountability
Security teams need rules that apply consistently across developers and sessions. They should not have to rely on each person choosing the right settings and keeping them enabled.
Through DeepKeep’s Policy Hub, administrators can configure rules by role or across the organization. These rules can address categories such as PII, credentials, and destructive commands, as well as custom terms tied to the company’s own sensitive information.
AI Lens is centrally managed by the administrators responsible for the coding agents. Developers cannot disable it.
Each session also produces an audit log, including device ID, user ID, and prompt content. If a developer changes a blocked request and tries again, security teams retain a record of the activity. They can review the sequence rather than seeing only the final attempt.
This connects policy enforcement with the context needed to investigate what happened.
Fit protection into the developer environment
AI Lens for Developers is built as a lightweight plug-in that uses the coding agent’s existing hooks. It adds monitoring and controls without requiring a separate full endpoint agent on developer machines.
Deployment options include VPC and on-premises environments. Air-gapped deployment is also supported where the coding tool and chosen model allow it. The deployment needs to fit the full workflow, including where the model runs.
AI Lens for Developers supports Cursor and Claude Code today. Support for GitHub Copilot, OpenAI Codex, Lovable, Windsurf, and additional tools is planned.
As coding agents take on more work, security teams need visibility into the actions that make that work possible. Which files were read, which data moved, which commands were proposed, and which policies were enforced all matter.
Developers can delegate tasks to an agent. The organization still owns the consequences.






















