Code agents in endpoint: visibility, control and audit to govern the new development risk

In recent months a silent actor has appeared within many engineering teams: he is not a human, nor a traditional service, but a programming assistant capable of reading files, running commands in the shell, calling external APIs and connecting with third-party integrations. These code "agents" - a prominent example is Claude Code by Anthropic - are executed on the developer's machine with the same permissions as the developer and therefore operate outside the perimeter of the security tools that traditionally protect the network or gateways.

This change is not trivial. Many security controls are designed to see and act when traffic leaves the device: SIEM, network monitors and gateways inspect communications in transit. But a local agent may already have read secrets, modified files or executed a command sequence before any package crosses the network. The action occurs in the endpoint and, unless that layer is also observed, it is out of reach. To better understand why this matters, it is important to remember that these agents often "live from the system": they reuse binaries and credentials already present in the machine rather than bringing their own, which makes it difficult to detect them with the classic filtering techniques. Security organizations and equipment have long been alerting about this way of operating, which in safety terminology is known as "living off the land"; for useful technical references, the MITRE ATT & CK documentation on related techniques can be consulted: MITRE ATT & CK - HOLBins / System Binary Proxy Execution.

What can be done when an agent runs commands with a developer's permissions and leaves no trace on the logs that the security team already collects? A solution that appears in this context is to place a layer of trust and control directly on the developer's device, next to the agent itself. Beyond Identity has called this component Zero: a "layer of trust" that is installed in the endpoint and that aims to offer three key things: real-time visibility, blocking or mitigation of unauthorized actions, and a cryptographically verifiable audit trail.

Zero's proposal is pragmatic: the adoption of controls in the developer's environment must be invisible in order not to break productivity. From the perspective of the engineering team the interaction with the agent should remain the same, but behind the scene Zero captures the context of the device (version of the system, protection state, disk encryption, Secure Boot and other position indicators), collects the process genealogy that started the session and binds it to a verified human identity, signing evidence with keys linked to the hardware of the team.

In the administrative console of Zero, for the first time for many teams, something that was previously a black box appears: the complete conversations between each developer and his agent, and - most importantly - the calls to tools that were executed during those conversations. When a seemingly inoculated request triggers the execution of a shell command or the reading of a file, the platform shows it with the exact command, its arguments and the resulting output. This visibility of the "invoked tools" transforms the perception of risk: it is no longer a suspicion and becomes concrete evidence.

Next to the sessions, Zero exposes the external connectors that agents have used: the so-called MCP servers, which are the bridges to databases, internal APIs, messaging platforms or cloud services. In many organizations the list of integrations that developers have connected on their own exceeds what security teams believed was allowed; the lack of revision of these access roads constitutes a vector of risk in itself.

Visibility without governance is only detection. Therefore Zero incorporates a layer of policies that are evaluated in real time before an action is implemented. Among the options that pay dividends quickly are the allowlist rules for MCP servers: only the connection to approved servers is allowed and the rest is blocked at the point of origin. You can also create tool controls: limit the use of Bash, allow file readings only within project routes or inspect the arguments of a call to allow or deny it. Also, device posture policies require minimum conditions - for example, active endpoint encryption or protection - to allow the agent to run; and, if the condition of the equipment changes during a session, the platform can re-evaluate and act as defined.

From the point of view of compliance, the most relevant difference is the evidence trail. The activity record generated by Zero is not a log file that an administrator can edit after: each entry is signed with a key linked to the hardware before leaving the device, creating a chain of evidence with a temporary seal and human attribution. For teams that must respond to audits under frameworks such as SOC 2, FedRAMP, HIPAA or PCI-DSS, it is easy to demonstrate effective controls. If you want to review official sources on audit and control requirements, you can consult the resources of the AICPA on SOC, the web of FedRAMP the documentation of the HHS on HIPAA and the page of PCI Security Standards Council.

In addition to blocking or allowing, the platform allows you to centrally manage what integrations are available: administrators can deploy approved MCP servers to agents of all developers from a console, avoiding manual configurations and ensuring that teams work only with official tools. Combined with the allowlist, this capacity makes governance operational and automatic, without adding friction to the developer's workflow.

All of this is summarized in a panel that provides an aggregate view of the risk associated with agents throughout the organization: how many devices are enlisted, what instances of the agent are active and where there are adoption gaps that might indicate that agents are executed out of control. For security teams that need to prioritize efforts, this telemetry is the starting point for informed decisions.

It is not a question of demonizing assistance tools: programming assistants offer real productivity. The challenge is that your operating model requires rethinking the security architecture: if the action occurs in the endpoint, that is where it must be measured and governed. The practical recommendation for teams that already use or plan to deploy agents is to start with visibility: only when it is known which actions are being implemented and by whom it is possible to design policies that mitigate risk without stopping developers.

If you want to know more about the manufacturer's solutions mentioned in this article, you can visit the Beyond Identity website at beyondidentity.ai and the agent's deployment page at agent.beyondidentity.com. To understand the broader phenomenon of agents and model extensions, industry is also moving towards safety frameworks and practices adapted to these new flows; OpenAI has documented extensibility approaches in the your blog, and analysis of abuse and mitigation techniques appear in resources such as MITRE.

In short, the endpoint programming assistants are a new layer of risk and opportunity. The effective strategy is to implement the device: to record, control and sign what happens at the time it happens, not to rebuild it later. Only in this way will security teams be able to integrate these agents into auditable controls that are appropriate to regulatory and business requirements.