Securing AI Agents: Lessons from microservices & Zero Trust
This post is a little different than my usual ones. It lives somewhere between my day job—thinking about identity, access, and governance at StrongDM—and a topic that seems to have taken over every architecture conversation lately: AI agents. You can’t swing a virtual stick these days without hitting a demo where an agent is booking meetings, writing code, or orchestrating cloud workflows. But with great autonomy comes great... attack surface. This is a longer, deeper dive into one specific corner of the problem space: how we govern and secure what these agents can actually do. If it reads a little nerdier than usual, that’s because it is. But if your AI agents are starting to look less like chatbots and more like coworkers with API keys, I think you’ll find it relevant.
AI agents are rapidly becoming a new force in enterprises, evolving into sophisticated digital co-workers. These autonomous, AI-driven programs can perceive, decide, and act within digital systems, offering capabilities far beyond traditional scripted chatbots or robotic process automation (RPA) scripts. From customer support bots that resolve complex issues to finance agents that analyze and even initiate transactions, AI agents are redefining how businesses operate. Unlike their predecessors, modern AI agents possess a remarkable degree of autonomy and adaptability, enabling them to pursue higher-level goals, interact with multiple applications, and make independent decisions.
The very qualities that make AI agents so powerful—their autonomy and ability to dynamically plan actions—also introduce unpredictability. Earlier generations of AI, like simple chatbots or recommender systems, only responded to specific prompts. In contrast, an autonomous agent can initiate actions independently, creating ambiguities in oversight and accountability. For instance, an AI agent integrated with HR and finance systems might decide to issue a refund or reconfigure a server without explicit human intervention. This level of initiative can quickly become a security nightmare if not properly governed.
At their core, AI agents introduce a new type of non-human identity within our digital systems—one that can act with substantial independence. This new paradigm has caught many organizations off guard. Just as human users require rigorous authentication, authorization, and oversight, these non-human agents demand similar scrutiny. However, the practices for doing so are still nascent. Key security requirements are emerging, including identifying human users to the agent, enabling the agent to securely call APIs on users’ behalf, managing long-lived agent workflows, and enforcing fine-grained data access so agents only see what the user is permitted to. Enterprises are currently scrambling to address these needs, often building ad-hoc, "DIY" controls due to the lack of an established blueprint for securing AI agents end-to-end.
AI Agents ~= Microservices?
While securing AI agents presents unique challenges, we can draw valuable inspiration from a field that previously dealt with a similar challenge of distributed, non-human actors: microservices. The shift to cloud and microservices over the past decade forced organizations to secure a complex web of APIs and automated services communicating with each other. This led to the development of robust security patterns that are highly relevant to AI agents today. At a high level, the industry learned to treat every service or workload as an independent principal with strict security controls, embodying the essence of modern zero trust architecture: even within your network, every request between components must prove its identity and be explicitly authorized.
Specifically, microservice architectures adopted several key practices that map well to the security needs of AI agents:
Workload identity + mTLs + e2e encryption: Instead of implicitly trusting a service because it resides on the internal network, each microservice is issued a unique cryptographic identity (e.g., an X.509 certificate or JWT). Services authenticate to each other via mutual TLS handshakes or token exchange, cryptographically verifying the origin of every call. This approach, pioneered in cloud-native systems, ensures that no service communicates with another without proof of identity. The same principle applies to AI agents: every agent instance should present credentials (certificates or tokens) that a target system validates on each interaction. By using strong, auto-rotating identities instead of static API keys or passwords, it becomes significantly harder for an attacker to impersonate an agent or intercept its communications. Additionally, all service-to-service communication is typically encrypted and authenticated, often via service mesh infrastructure, ensuring that messages cannot be read or tampered with even if an attacker sniffs the internal network.
Fine-Grained Access Control (FGAC): Identity alone is insufficient; it's also crucial to restrict what each service or agent is allowed to do. In microservices, this led to the adoption of fine-grained authorization policies, often implemented via policy engines or attribute-based access control. Instead of a service having blanket "admin" rights, it receives only the minimum permissions it absolutely needs—the principle of least privilege. For example, a reporting microservice might only be allowed to read customer data but never delete it. Similarly, an AI sales agent designed to draft emails and log notes should only have permission to create records in the CRM, not to drop entire tables.
Delegated access (OAuth2): When microservices need to access data on behalf of a user, they commonly use protocols like OAuth2 rather than storing user passwords. A classic pattern involves the OAuth2 client credentials or token exchange flow, where the service obtains a scoped token that specifies, "This is Service X acting for User Y, allowed to do Z." This enables backend services to make delegated API calls with bounded scopes, meaning that if the token is leaked or misused, its powers are limited and time-bound. AI agents should follow this practice. For instance, if an AI customer support agent needs to retrieve a user’s order history from an e-commerce API, it should use the company’s OAuth mechanism to request a token scoped to "read order history for user X," rather than logging in with a master admin credential.
In summary, the microservices world taught us to treat machine identities seriously and eliminate implicit trust. We implemented strong identities, thorough authentication on each request, fine-grained authorization, encryption in transit, and robust auditing.
AI Agents != Microservices
While many microservice best practices carry over, AI agents are not identical to microservices. Their unpredictability and learning capabilities introduce aspects where the traditional model falls short, requiring adaptation.
Dynamic and unpredictable behavior: Microservices execute code that developers explicitly wrote and vetted. An AI agent, on the other hand, can dynamically devise new action sequences in response to changing inputs. This means an agent might attempt an operation no one explicitly anticipated. Static roles and permissions cannot fully capture the fluid context in which agents operate. What’s needed are context-aware, just-in-time permissions that adjust based on the agent’s current task, risk level, and observed behavior.
Extended privileges and lifecycle: Microservices typically run with fixed scopes and are often short-lived processes designed to perform a single task. AI agents, however, might persist and evolve over time; some agents even generate new code or spin up sub-agents as part of their operation. This blurs the boundary of what exactly we are securing. If an agent can instantiate new helper processes to handle subtasks, those new processes also need identities and oversight. A misconfigured agent could accidentally launch a tool that bypasses normal controls. In contrast to microservice security’s assumption of a relatively static topology, agent security must handle a more fluid, self-modifying environment.
Human+AI : With microservices, human intervention for routine API calls was rarely considered, as the logic was deterministic. But AI agents can venture into ambiguous territory where a human approval step is prudent. We might need to define which agent-initiated actions require a "checkpoint"—be it a manager’s approval, a secondary confirmation from another system, or additional validation. This concept of human-in-the-loop checkpoints adds an extra layer on top of microservice-style controls.
Its worth noting that, AI agents are susceptible to novel attack vectors, such as prompt injection, where malicious inputs can trick the agent into performing unintended actions. These attack vectors are unique to agents and have no equivalent in the microservices space. Hence, the ability to map security principles from microservices 1:1 to agents will not cover the idiosyncratic security challenges of agents.
The bottom line is that microservices security provides a necessary foundation, but AI agents demand an even more fine-tuned and vigilant approach. We must assume these agents will surprise us, so our security model has to be dynamic, granular, and infused with skepticism at every turn.
Zero Trust: Agent edition
To effectively govern and secure autonomous AI agents, organizations should adopt a forward-looking, Zero Trust mindset combined with granular policy guardrails. In practice, this means treating AI agents as untrusted by default—just like any external user or service—and enforcing strict verification, least privilege, and continuous oversight. Therefore, my key principles for robust AI agent security include:
Trust, but verify: Every interaction involving an AI agent should require explicit authentication and authorization, as if it were an external entity. No agent gets a free pass simply for being "inside" the firewall. We must "assume the worst"—that any agent or component could be compromised—and verify every call and request in your systems accordingly. This includes internal API calls, database queries, file access, and more. Each time, the agent’s identity, the action it’s attempting to perform, and the context should be meticulously checked against policy.
Least privilege access: As with microservices, granting AI agents the minimum privileges they need is crucial—arguably even more so, given their inherent unpredictability. If a customer support agent only needs to read knowledge base articles and create support tickets, that’s all it should be allowed to do. Least privilege significantly limits the damage if an agent malfunctions or is hijacked.
Dynamic, Just-In-Time access: Given the fluid nature of AI workflows, it’s wise to use short-lived credentials and dynamic privilege escalation rather than static keys or permanent admin rights. In cloud security, we’ve learned to use ephemeral tokens (e.g., AWS IAM roles that issue temporary credentials for 15 minutes). AI agents should be equipped similarly. Issue them short-duration tokens or certificates that expire quickly, so even if leaked, they cannot be abused for long. If an agent needs elevated access for a special task, adopt a just-in-time access model: have it request the higher privilege at the moment of need, obtain approval (automated or human), and then auto-revoke it after a brief window
Continuous Monitoring and Verification: AI agents operate continuously, potentially making thousands of decisions. Security cannot be a one-time gate at login; it must be an ongoing process. Organizations should monitor agent behavior in real-time and flag anomalies. This could involve tracking metrics such as: Is the agent suddenly reading an unusual amount of data? Is it accessing systems it has never used before? Such monitoring might feed into an automated risk scoring system that can dial down permissions or alert security staff if an agent acts out of bounds. Equally important is maintaining detailed logs of all agent actions—every API call, every critical decision—to enable forensic analysis and accountability.
Policy-as-Code: This is arguably the most critical element and is key for FGAC. In a complex, dynamic environment, manual or ad-hoc security rules will not scale. Enterprises should express their AI governance and security rules as code, similar to how infrastructure-as-code revolutionized operations. Using a policy-as-code framework ensures that all these decisions (what an agent can access, when to require human approval, what constitutes abnormal behavior) are defined in a versioned, testable, and automatable way. For example, a policy rule might state: "AI agent X may only access database Y during business hours and must have an active user session token if it’s reading personal data." By encoding this in a policy engine like StrongDM’s Cedar Policy Engine, enforcement becomes consistent across all systems. Policy-as-code also simplifies audits by providing a single source of truth for agent permissions. It's an approach that vendors have promoted to unify security checks in an auditable, automated framework and is increasingly considered a best practice.
There’s one wrinkle to FGAC and policies: where and who evaluates these policies?
If every system an agent touches—databases, SaaS APIs, internal services—enforces policy independently, it becomes nearly impossible to manage or reason about the agent’s effective privileges. Policies will diverge, gaps will emerge, and no centralized system will have visibility into what the agent is actually allowed to do in any given context. The result is an incoherent security posture vulnerable to drift and privilege escalation. The solution is to shift policy enforcement up to the agent orchestration layer—the component that mediates between the agent’s reasoning loop and the concrete actions it takes on enterprise systems. By enforcing FGAC policies in the orchestrator, organizations can apply consistent, context-aware rules across all tools and services the agent might access. Backend systems should still maintain static guardrails, but dynamic policy—governed by who the agent is, what data it has seen, what user it may represent, and what the current risk posture is—must be enforced at the orchestration layer, before actions are executed.
I started this (lengthy) post drawing on an analogy between AI agents and microservices. At first glance, both appear similar. Both are automated actors operating in distributed systems, invoking APIs, exchanging data, and requiring authentication and authorization. It is natural—and useful—to borrow proven patterns from microservices security as a starting point for governing agents.
But this is ultimately an analogy, and analogies can introduce dangerous biases. Where microservices execute predefined, deterministic code, agents reason dynamically, generate novel actions, and evolve their internal state over time. Microservice interactions are typically bounded; agent workflows are stateful, open-ended, and prone to influence by untrusted inputs. Relying too heavily on the analogy risks underestimating these differences and overlooking the need for new control points—especially around information flow, prompt lineage, orchestrator policy enforcement, and dynamic privilege management.
The core lesson is this: we should absolutely leverage the security insights of the microservices era, but we must also recognize where agents fundamentally differ, and design accordingly. The cost of getting this wrong is high—not just fragmented policy, but real risk of uncontrolled agent behavior.