Margin of Safety #29: Agents vs Microservices

Will agent security look like microservice security—or something new and different?

Earlier this year, we wrote about the different definitions of agents, ranging from LLMs driving the control flow (Anthropic’s definition) to AI being used for at least one step in the context of an otherwise classical program’s execution loop (many people’s marketing definition). As we look around now, we definitely see instances of the former – especially around things like high level code assistants – but we see even more examples of the later, especially around business process automation (BPA) or its next-gen variant of agentic process automation (APA). We’re also seeing a number of claims that enterprise adoption of these agents will drive reinvention of the security stack.

We think there is a strong core of truth to these claims, since new technology often comes with new security needs. But we’re also suspicious that not everything will change. It’s true that the maximally permissive implementation of agents would necessitate broad reinvention. But how many enterprises launch the maximally permissive implementation of anything? And of the enterprises that do favor that approach, how many are then deeply concerned about fully mitigating the resulting security risks?

Instead, we expect many enterprises to make pragmatic choices implementing and rolling out agents, particularly in the short and medium term and for BPA/APA focused workloads. Pragmatism typically means defaulting to reusing existing concepts and design patterns. In turn, we expect this implies workloads that are (for example) defined well enough to support a release cycle in which major behavioral changes are documented, tested, and broadcast to relevant stakeholders prior to deployment. It also implies a desire for standard semantics for rollouts, monitoring, and rollback; ideally using existing tools.

If we assume those constraints, then the incremental security surface area decreases in some ways. For example, agents can only be so ephemeral if they’re going through a standard release cycle. Individual instances may be ephemeral, much like existing serverless functions, but the workload definition – along with key properties like the set of systems the workload may try to interact with – will likely be well defined, monitored, and tested as part of the release process.

Viewed through this lens, we think that existing microservice semantics may be sufficient to handle many agentic system needs. Microservices provide a framework for loosely coupled, high-throughput technical systems with a high degree of interservice interaction and interoperability. The question then is where microservice semantic reuse is likely to break down. We expect a handful of places.

Democratization:

Versus classic microservices, which required a technically skilled team to build, deploy, and maintain, agents promise a technological democratization. The core promise of next gen APA/BPA is that a reduction in the fixed costs to create an automation (plus, potentially, the variable cost of maintenance) will enable less technical teams to automate more things at low cost.

This has both operational and security implications. If creating a service shifts from a specialty function – which only select members of your organization can compete -- to something more akin to creating a well written document – possible for competent individuals across the entire organization – then control systems need to be able to keep pace with everything that democratization implies.

Ownership:

We think an often under-emphasized challenge will be that of managing ownership and identity. If you democratize agent creation, are you also going to democratize the creation of machine identities for those agents? Answering “yes” is a fast path to unmanageable identity sprawl, creating an enormous and unauditable attack surface. But answering “no” forces difficult tradeoffs.

Without the ability to create new, bespoke identities, what do employees do? They might reuse pre-provisioned, generic service accounts, which almost certainly carry far more permissions than necessary. A more common pattern might be to have the agent inherit the permissions of its creator. This seems simple at first but creates a profound lifecycle management headache. What happens to the agent and the processes it runs when the employee who created it quits, gets laid off, or is reorganized into a new role? Tying critical business automation to the employment lifecycle of a single individual is a fragile and unsustainable model. We’re both curious to see where industry lands and interested in smart technological solutions to this problem.

Excess Permissions:

This ownership dilemma flows directly into another classic security challenge: excess permissions. By default, an agent’s permissions will likely be broad, designed to cover every possible action it could take, rather than what it should take in a specific context. This violates the well-established principle of least privilege.

Whether the permissions are inherited from a user or assigned via a dedicated service account, they will probably be aligned to the general capabilities of the workflow, not the specific needs of a single instance. Consider a customer service agent designed to automate looking up order details. The general workflow needs access to the entire customer database. However, any single instance of that workflow, triggered by a request from “Customer A,” should ideally be scoped to access only the details for Customer A. How do you enforce that kind of just-in-time, dynamically scoped permissioning? What do you do if the underlying CRM system was designed for human interaction and has no concept of such granular, programmatic scoping? The likely default will be to operate with excess permissions, creating a significant risk if the agent is ever compromised or behaves unexpectedly.

Conclusion:

If you’re deploying agents, we’d love to hear your thoughts on where existing semantics are or aren’t working for you! And if you aren’t deploying agents but have a strong opinion, reach out to us at jpark@forgepointcap.com and kshih@forgepointcap.com