As enterprises hand AI agents the ability to write code, access sensitive data, and take action across their systems, a critical question looms: how do you give these autonomous tools enough access to be useful without giving them enough to cause serious damage? According to Alex Zenla, CTO and co-founder at Edera, many organizations are overlooking a key point. Keeping a credential hidden from an agent is only one step. Without explicitly defining the behaviors an agent is allowed to perform, credential elimination becomes “a gate with no fence protecting it.” Traditional identity and permissions models, which tend to treat agents like human users by granting broad tranches of access, are simply too rigid for autonomous computation.
In this VMblog Q&A, Zenla discusses Edera’s recently introduced Bounded Authority, which is built on object capabilities, a long-researched computer science concept designed to avoid the risks of ambient authority. She explains how revocable, delegable, and narrowly scoped permissions can limit the impact of prompt injection, reduce the exposure of MCP servers, and keep subagents from inheriting the full authority of their parents. She also offers advice for platform engineering and security leaders moving AI agents from experimentation into production: assume everything can go wrong, and build security that spans from the hardware to the application layer.
++
VMblog: AI agents are increasingly being given the ability to write code, access sensitive data and take action across enterprise systems. What’s the biggest security risk organizations are overlooking as they give agents more autonomy?
Alex Zenla: The thing most organizations overlook is that protecting a credential from being visible to the agent is only one step in preventing rogue access by an agent. You must explicitly define allowable sets of behaviors by the agent and grant only those operations in a verifiably unforgeable way. If you don’t do this, the risk is that although the credential itself cannot be leaked, you can execute actions that could grant permissions to other systems or destroy systems, turning credential elimination into a gate with no fence protecting it. Edera protects this by enabling you to downscope access permissions safely and easily and share segments of that authority with other systems.
VMblog: You’ve argued that AI agents are often given far more authority than they actually need. Why are traditional approaches to identity, permissions and secrets management insufficient for securing autonomous agents?
Zenla: We often grant permissions in identity systems like they are humans, providing tranches of access. For example, we may grant read:repository on GitHub. GitHub even allows you to restrict a token to a single repository, but what it does not do is restrict what you can read in the repository. It gives quite a bit of access with that permission, whereas the agent may only need to read specific types of resources. We’ve made these systems too rigid for autonomous computation. Edera’s bounded authorities grant access to permissions in a controlled way, granting only specific access and allowing delegation of access in a revocable way.
VMblog: Edera recently introduced Bounded Authority, built on object capabilities. How does this approach fundamentally change how an agent is given access and what they are allowed to do, particularly when an agent is compromised or manipulated through prompt injection?
Zenla: Edera built Bounded Authority on object capabilities, a long researched computer science concept, because it provides the ability to grant access to systems without risking ambient authority. Edera’s bounded authorities are revocable, which means if an agent performs an incorrect action, the authority can be instantaneously revoked. Additionally, if a prompt injection occurs, the effects of the injection can only be scoped to the explicitly allowed actions by the capability. Agents can also delegate those actions and descope the authority, ensuring subagents do not have the full authority of their parent. These features enable a truly secure autonomous system, without the risks imposed by ambient authority.
VMblog: MCP servers are becoming a critical connection point between AI agents and enterprise infrastructure. What makes them particularly attractive targets for attackers, and how can organizations limit the damage if one is compromised?
Zenla: MCP servers often provide a wide range of actions, and can only steer agents to calling them by their tool call information. These systems often are granted coarse permissions, rather than fine-grained permissions. With bounded authorities and capability-aware MCP, you can ensure that MCP servers only present actions which are reasonable to take, but you can also ensure the scope of those actions are restricted to specific entities. Reducing the amount of data / actions behind the MCP is ultimately how we prevent misuse of MCP access in autonomous systems.
VMblog: As enterprises move from experimenting with AI agents to deploying them in production, what needs to change about the underlying security architecture? What advice would you give platform engineering and security leaders preparing for this transition?
Zenla: We have to assume that everything can go wrong, and build systems resilient for that. Autonomous systems are a new use case that must span everything from hardware to the highest level of software, and it must be designed for a wide range of risks. Edera’s Bounded Authority enforces their security from the hardware all the way to the application layer. Systems like this are the only way to give true security to AI agents in production.
