Ask your engineering teams a simple question: how does your AI agent authenticate when it calls an internal tool? In many organizations, the honest answer is some version of “there’s an API key in an environment variable.” Often it’s the same key that three other agents, two batch jobs and a developer’s laptop also use. Sometimes it’s a personal access token belonging to whoever built the prototype.
Now ask a follow-up: if one of those agents were manipulated by a prompt injection and started calling tools it shouldn’t, how would you know, and how would you stop it?
If you’re a CISO, security architect or head of application security, this article is for you. AI agents are quickly becoming some of the most privileged and least governed workloads in the enterprise. The good news is that the controls you need already exist in cloud-native security. They just haven’t been applied to agents yet.
Why agents are a new kind of security problem
Traditional applications follow code paths that developers wrote and reviewers approved. Agents decide at runtime which tools to call, in what order, with what arguments, based on natural-language input that may come from customers, documents or other agents. That changes the threat model in a few important ways.
Agents are confused-deputy machines. An agent acts with whatever permissions its credentials grant. If an attacker can influence its input, through a poisoned document, a malicious email or a compromised upstream agent, they can steer those permissions.
Tool access is expanding fast. With protocols like the Model Context Protocol (MCP), connecting an agent to a new tool takes minutes. Each MCP server is effectively a new API surface, often deployed by a product team without a security review.
Agents talk to agents. Multi-agent systems mean that requests pass through several autonomous hops. Without strong identity, the last hop can’t tell whether the original request came from a legitimate user, another trusted agent or an attacker.
Shared credentials erase accountability. When many workloads share one key, logs can’t distinguish them, keys can’t be rotated without breaking things, and revoking access for one compromised agent means breaking all the others.
What zero trust means for agents
Zero trust isn’t new. Its principles (never trust the network, authenticate every request, grant least privilege, assume breach) have been applied to microservices for years. Applying them to agents means a few specific things.
1. Every agent and tool gets its own identity
Replace shared API keys with workload identities: short-lived, automatically rotated cryptographic credentials issued to each agent, tool and MCP server. The SPIFFE standard is the common way to do this in cloud-native environments. Each workload gets an identity like spiffe://corp.example/ns/claims/agent/triage, which is tied to where and how it runs, not to a secret someone can copy.
2. Every call is mutually authenticated and encrypted
All traffic between agents, tools and services uses mutual TLS, where both sides prove their identity. An attacker who gets onto the network can’t impersonate an agent, and an agent can’t be tricked into calling a fake tool.
3. Access is explicit and least-privilege
Write access policies that say which identities may call which operations: the triage agent can read policy documents but not issue payments, and only the settlement service can call the payments API. Deny by default. These policies become the security team’s control surface for agent behaviour, enforced by the platform rather than by each agent’s code.
4. User context travels with the request
When an agent acts on behalf of a user, the user’s verified identity and scopes should travel with the request (for example as an OAuth token validated at each hop), so a tool can enforce both “is this a trusted agent?” and “is this user allowed to do this?”.
5. Every action is recorded and attributable
Each tool call should be recorded with the caller’s identity, inputs and outputs, in a record that can’t be silently altered. When something goes wrong, you need to reconstruct exactly what the agent did and on whose behalf.
Making it practical: put the controls in the runtime
The biggest mistake is asking every agent team to implement these controls themselves. They’ll do it inconsistently, and every new agent framework will need its own integration. The better approach is to enforce identity, encryption, policy and audit in the runtime the agents run on, so every agent gets them by default.
This is where open-source cloud-native infrastructure helps. Dapr, a graduated CNCF project, runs a sidecar next to each workload. Its built-in certificate authority issues SPIFFE-based identities to every application, all sidecar-to-sidecar traffic is encrypted with mTLS by default, and access-control lists can restrict which application IDs may invoke which operations. Because agents built with frameworks like LangGraph, CrewAI or Google ADK can run on Dapr without rewriting them, the same controls apply regardless of which framework a team picked.
Commercial platforms are extending this model specifically for agents and MCP servers. Diagrid, for example, gives each agent and MCP server on its Catalyst platform a cryptographic identity with mTLS by default, supports propagating verified user identity through agent calls, and can cryptographically sign each workflow’s execution history so the record of what an agent did is tamper-evident. Whichever platform you use, the principle is the same: security teams should configure policy once, centrally, rather than review every agent’s authentication code.
A 90-day playbook for security leaders
Days 1–30: Discover.
- Inventory every AI agent and MCP server in production and pilot.
- For each, record what credentials it uses, what tools it can call and whose data it can access.
- Flag every shared credential and every personal token used by an agent.
Days 31–60: Contain.
- Move the highest-risk agents (those with write access to money, customer data or production systems) onto a runtime with workload identity and mTLS.
- Write deny-by-default access policies for those agents’ tool calls.
- Rotate or revoke the shared credentials they were using.
Days 61–90: Govern.
- Make the secured runtime the default path for any new agent or MCP server.
- Require an identity and an access policy as part of the deployment checklist.
- Send agent execution records to your SIEM, and define alerts for policy denials and unusual tool usage.
- Run a tabletop exercise: a prompt-injected agent tries to exfiltrate data. Can you see it, stop it and reconstruct it?
Questions to ask your teams and vendors
- Does each agent have its own identity, or does it share credentials?
- Is agent-to-tool and agent-to-agent traffic encrypted and mutually authenticated?
- Where are access policies defined, and who can change them?
- How does the user’s identity and permission scope reach the tool that finally acts?
- Can you produce a tamper-evident record of every tool call an agent made last Tuesday?
- If one agent is compromised, how quickly can you revoke its access without affecting others?
Conclusion
AI agents don’t need an entirely new security discipline. They need the zero-trust practices that already work for cloud-native services (workload identity, mutual TLS, least-privilege policy and verifiable audit) applied consistently and enforced by the platform rather than left to each team. Security leaders who push for that now, while agent estates are still small, will avoid having to retrofit it across hundreds of agents later. A runtime with identity and audit built in is the most direct way to get there.
