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.
