Can You Revoke an Agent Without Disabling Its Developer?
In the rapidly evolving realm of cybersecurity, the traditional tenet of "least privilege" faces new challenges through the lens of agentic development. This approach exposes critical limitations in conventional identity and access management, prompting a reevaluation of how permissions are granted and revoked. Security professionals must now confront a pressing question: can an agent be revoked without disabling the developer who authorized it?
Let’s take into consideration a scenario involving a developer who authorizes an agent to make modifications to a GitHub repository. If that agent utilizes the developer’s personal token for its operations, it effectively inherits access to every repository the developer can reach. This includes permissions for crucial actions like merging code, access to Continuous Integration/Continuous Deployment (CI/CD) environments, and even downstream credentials linked to those systems. This phenomenon can be described as "ambient authority"; it refers to the dangerous capability of performing actions that extend beyond the original task for which access was granted.
A significant challenge arises when agents operate under a developer’s credentials. Revoking the agent’s access under these conditions often means disabling the developer’s account as well, creating a cascade of administrative headaches. To mitigate this risk, security teams are compelled to clearly differentiate between autonomous workloads (agents) and human identity (developers).
To this end, it is imperative that agents possess independently defined identities with permissions specifically tailored to their tasks. This adjustment not only enhances accountability—allowing teams to track the actions taken by each agent—but also simplifies the process of investigating discrepancies or security breaches. Importantly, it allows for the revocation of an individual agent’s authority without disrupting the developer’s activities, thereby maintaining operational continuity.
The Missing Link: A Trusted Broker
One of the most intriguing innovations in agentic security is the concept of a trusted broker, which serves as an intermediary between an agent and the systems it aims to access. A variety of solutions exist under this umbrella, including MCP (Managed Cloud Proxy) proxies and different architectural designs using authorization services and gateways. These solutions all address a fundamental question: how do organizations determine which agents can access specific resources, under what circumstances, and for how long?
A noteworthy aspect is that the agent should never have the authority to decide its own limits. Such decisions must be enforced by an independent system capable of authorizing specific operations without exposing sensitive credentials. For instance, if an agent tasks itself with fixing an issue in a GitHub repository, the developer can authorize this operation once without granting unrestricted access. A trusted intermediary could facilitate this process by allowing the agent to read the repository, make changes to designated branches, and submit a pull request—all while maintaining robust security protocols. Importantly, these permissions could be time-limited, expiring after an hour, thereby safeguarding developer credentials from broad misuse.
Navigating the complexities of agentic security requires striking the right balance. If access controls are too stringent, developers may circumvent them; conversely, overly permissive settings can undermine the purpose of access control altogether. The overarching goal is to enable secure delegation while preserving the convenience of unrestricted access.
The landscape of agentic security may soon undergo a transformation comparable to pivotal architectural shifts in technology. Developers, open-source projects, and commercial entities are actively exploring novel approaches to identity management, delegation, authorization, and policy enforcement. While some organizations are building custom solutions around existing Identity and Access Management (IAM) systems, others are investigating the feasibility of dedicated intermediaries that evaluate access requests before agents can engage with external resources.
Currently, the trusted broker is not a universally accepted concept, and there’s no assurance that one architecture will emerge as the standard akin to Kubernetes. Several critical issues remain open for discussion, including policy decisions, credential management, latency, availability, and auditability. Nonetheless, the necessity for a reliable intermediary becomes increasingly clear: there is an urgent need for a trusted broker that translates human intentions into narrowly defined, enforceable authority tailored for autonomous software.
MCP Servers: A New Software Supply Chain
At the forefront of agentic operations is the Managed Cloud Proxy (MCP), a vital component through which agents connect to external tools and data sources. Serving as both an integration mechanism and a security boundary, MCPs are pivotal in maintaining the integrity of operational environments.
However, a compromised MCP server poses significant threats, potentially serving as a backdoor into an agent’s workflow. If these servers or tools operate with access to shared filesystems, processes, or credential stores, a malicious or compromised element could access sensitive secrets belonging to various tools in the system.
Credential theft is not the sole concern. A compromised server can manage to return altered information that can affect an agent’s actions even before it executes any tasks. In other words, an attacker does not necessarily need to compromise the agent directly; they can manipulate the context the agent consumes.
To mitigate these risks, conventional security practices like provenance tracking, cryptographic signing, and ensuring build integrity need to be applied persistently to MCP servers, agent tools, and the model weights. Organizations must have comprehensive knowledge regarding the origins of these components, any modifications they may have undergone, and the specific authority granted to them within an operational environment.
Ultimately, a layered security approach is essential. It should incorporate strong isolation practices, independently managed identities, narrowly scoped permissions, controlled network access, and sufficient observability to allow organizations to ascertain the actual activities and impacts of autonomous agents.
In summary, the rapidly changing landscape of agentic security underscores the growing importance of clearly distinguishing between human and agent identities, leveraging trusted intermediaries, and ensuring security practices are robustly extended to all operational components.