NewsCSO Online

    The developer laptop just became production. Now what?

    Share
    For decades, enterprise software development relied on an assumption that developers could experiment relatively safely because there were safeguards between their work and production. Development, staging and production had different rules, with human intermediaries making judgments about what was ready to move forward. Testing also assumed that software would behave predictably when executed again. Coding agents are upending both assumptions. Developers now run autonomous software on laptops containing GitHub tokens, SSH keys, cloud credentials and authenticated browser sessions. They’re connecting agents to MCP servers, granting access to repositories and services, and copying suggested commands into terminals without always understanding what those commands will do. When permission prompts become an obstacle, it’s tempting to click through them or enable unrestricted access. Developers are inventing security policies on the fly. The result is that the developer laptop has become an extension of production . An agent can reach systems that previously required deliberate human intervention, often using permissions granted for an entirely different purpose. Unlike conventional software, an agent may take different actions when presented with the same task because its context and decisions change. CISOs now face a fundamentally different challenge: governing autonomous software that already holds active pathways into production. The security control we never recognized was human judgment Where human developers and coding agents diverge most sharply is in judgment, not technical capability. Developers understand what state their code is in, whether it’s something they’re testing or something that’s production-ready. They understand what their credentials permit them to do, but also when and how those credentials should be used. There’s an implicit compartmentalization between having access and exercising it. An AI agent is much more single-minded. If an available credential helps accomplish the task, the agent uses it. Agents don’t recognize the distinction between what is technically possible and what policy permits. Consider an agent asked to troubleshoot a failing application. It discovers production credentials on the developer’s laptop and determines that querying the live database is the fastest way to diagnose the problem. It might modify production data while attempting a fix, even though the developer intended only to investigate a local issue. No vulnerability needs to be exploited. The agent simply uses available authority to pursue its assigned objective. Traditional development pipelines weren’t designed around software that independently decides which systems to access and what actions to take. Security controls must now account for behavior that can’t be fully anticipated from the original request. A sandbox can contain an agent without containing its authority Sandboxing has emerged as an obvious response to the risks of autonomous agents . By isolating execution inside a container, virtual machine or microVM, organizations can limit an agent’s ability to interfere with its host or other workloads. Strong isolation is essential, particularly when agents execute untrusted code or interact with potentially malicious tools. A microVM with its own guest kernel can provide a stronger boundary than a conventional container sharing the host kernel. But isolation answers only part of the security question. An agent sandbox that blocks all external access is as useful as a computer encased in cement at the bottom of the ocean. An agent doesn’t have to escape its sandbox to cause a security incident. It can misuse perfectly legitimate permissions, send sensitive information through an authorized network connection or make destructive changes using credentials deliberately provided to it. Isolating execution is useless unless you also precisely control what that workload can reach. A secure sandbox containing unrestricted credentials still leaves an enormous attack surface. Can you revoke an agent without disabling its developer? Security professionals are familiar with least privilege, but agentic development exposes the limitations of conventional identity and access management. Consider a developer who authorizes an agent to modify one GitHub repository. If the agent uses the developer’s personal token, it may inherit access to every repository that developer can reach . That could include merge permissions, CI/CD environments and downstream credentials associated with those systems. This is ambient authority: the ability to perform actions beyond the particular task for which access was originally intended. Even a relatively narrow token may authorize repeated actions when the agent only needed permission to perform the action once. When an agent operates under a developer’s credentials, revoking its access can also mean disabling the developer. Security teams need to separate autonomous workloads from human identity. Agents should have independently defined identities, with permissions delegated for specific purposes. That makes it possible to track what each agent did, investigate where something went wrong and revoke an individual agent’s authority without disrupting its developer. The missing link is a trusted broker One of the most interesting developments in agentic security is the emerging idea of a trusted broker that sits between an agent and the systems it wants to access. Some approaches are described as MCP proxies. Others use authorization services, gateways or different architectures. What they’re circling is the same fundamental problem: how do we decide which agents can access which resources, under what circumstances and for how long? Crucially, the agent cannot be responsible for deciding the limits of its own authority. Those decisions must be enforced by a separate system that can authorize individual operations without surrendering the credentials that make them possible. Imagine asking an agent to fix a GitHub issue. Instead of granting unrestricted repository access, the developer authorizes the task once. A trusted intermediary could then permit the agent to read the repository, push changes to a designated branch and open a pull request. Those permissions could expire after an hour, without exposing a broadly reusable developer credential. This is the core tension agentic security has to resolve. Grant too little access and developers abandon the controls. Grant too much and isolation becomes irrelevant to the damage an authorized agent can cause. The goal is to make secure delegation as frictionless as unrestricted access. Agentic security may be approaching a comparable architectural moment. Developers, open-source projects and commercial vendors are experimenting with approaches to identity, delegation, authorization and policy enforcement. Some organizations are building their own controls around existing IAM systems. Others are exploring dedicated intermediaries that evaluate requests before allowing agents to reach external resources. The trusted broker is not yet a universally defined component, and there’s no guarantee one implementation will become the equivalent of Kubernetes. Questions about policy decisions, credential custody, latency, availability and auditability remain open. But the missing function is becoming clearer. We need a dependable intermediary that translates human intent into narrowly defined, enforceable authority for autonomous software. MCP servers have become a new software supply chain MCP is one of the principal ways agents connect to external tools and information. That makes it both an important integration mechanism and a security boundary. A malicious MCP server can become an indirect route into an agent’s workflow. If servers or tools execute with access to shared filesystems, processes or credential stores, a compromised component may be able to read secrets belonging to another tool. But credential theft isn’t the only concern. A compromised server can return manipulated information that influences an agent’s subsequent actions even before the agent uses the tool. An attacker doesn’t need to compromise the agent—only the context it consumes. The familiar disciplines of provenance, signing and build integrity need to extend to MCP servers, agent tools and model weights. Organizations should know where these components originated, whether they’ve been modified and what authority they receive when introduced into an environment. The answer is layered security: strong isolation, independently managed identities, narrowly scoped permissions, controlled network access and sufficient observability to understand what agents actually do. Why agent security belongs in the execution path Containerization demonstrated that security works best when guardrails are baked directly into developer platforms without stripping away speed. Kubernetes eventually made it possible to enforce common security and operational policies across distributed workloads without requiring every developer to become an infrastructure expert. Agentic development needs a comparable shift. The longer-term opportunity is to move from granting persistent access to delegating task-specific authority. Developers need a way to authorize an agent to fix one issue or open one pull request without surrendering standing keys. Laptops are production endpoints now, and they won’t revert back to safe sandboxes. Security teams must protect developer speed by embedding the boundaries that human judgment used to handle manually directly into the infrastructure.

    More on production

    Other advisories

    Other news entries

    Source: https://www.csoonline.com/article/4247458/the-developer-laptop-just-became-production-now-what.html

    ID