Traditional IAM was built for humans. AI agents break every assumption it rests on — and that gap is where most AI security incidents begin.
The way software interacts is changing. AI agents call MCP servers. Applications orchestrate agents. Agents talk to other agents. The number of machine-to-machine interactions is growing faster than human-to-machine ones.
Yet most security infrastructure was designed for a simpler world: one where a human user authenticates once, gets a session token, and accesses resources. Traditional Identity and Access Management (IAM) systems excel at this. But they were never designed for the patterns we see in modern AI infrastructure.
The problem with identity-centric security
Traditional IAM focuses on identities. You have a user. You assign them permissions. They access resources. The security boundary is the identity itself.
This breaks down when your "users" are AI agents making thousands of requests per minute, when those agents chain through multiple services, and when the content of each request matters as much as who sent it.
Consider a typical AI application: a web app connects to an MCP server, which calls an agent, which accesses a database tool. In a traditional IAM model, you would manage permissions on each resource independently. But what about the relationship between the app and the agent? What about controlling what the agent can actually say to the MCP server? For a closer look at how agent identity works in practice, see AI Agent Identity: Why Agents Need Their Own Credentials.
Connection-centric security
A more effective approach secures the connections between entities rather than the entities themselves.
Every interaction in your AI stack passes through a defined connection. Each connection has two types of controls:
- Guardrails: Content-level controls that define what can be requested and returned. Think of these as semantic boundaries on the communication itself.
- Policies: Operational controls like rate limits, geographic restrictions, time-based access windows, and volume caps.
Both are applied bidirectionally. You can control what an application sends to an agent and what the agent sends back. This is not just authentication, it is full-spectrum governance of every interaction. For a broader treatment of what this looks like in a complete governance program, see what is AI agent governance?.
Why bidirectional matters
Most security tools focus on inbound requests: who is allowed to call this API? But in AI infrastructure, outbound responses are equally critical.
An MCP server might receive a perfectly valid request but return data that should not leave the system. An agent might be authorized to call a tool but produce a response that violates content policies. Without bidirectional controls, you only see half the picture.
First-class credentials for every entity type
A connection-centric model requires treating applications, MCP servers, and agents as equal participants in the security model:
- Applications register and receive credentials. They define which other entities they can connect to and what controls govern those connections.
- MCP servers get a full authentication and authorization layer, eliminating the need to build custom auth middleware for each server.
- Agents can be external services or built and hosted directly on the platform.
Each entity type has the same security primitives: credentials, connections, guardrails, and policies. There is no second-class citizen in the stack.
Getting started
If you are building AI applications that involve MCP servers, agents, or multi-service orchestration, the security of those interactions should not be an afterthought. A connection-centric model gives you the right primitives from the start: governed connections, bidirectional content controls, and a shared audit trail that covers every entity in your stack.
For a broader view of the threat landscape, AI Agent Security: The Complete Guide covers the full set of risks and mitigations. Teams evaluating whether to build or buy this layer can find a structured comparison in AI Agent Governance: Build vs Buy.
For how connection-centric governance applies to MCP tool use specifically, see registering and governing MCP servers.
Common questions
Why can't I just use my existing identity provider for AI agents? Existing identity providers handle human authentication well — SSO, MFA, session management. They were not designed to issue and manage credentials for machine principals at the volume and velocity AI agents require, nor to enforce content-level guardrails on what passes between services. A connection-centric security layer complements your identity provider rather than replacing it: humans still authenticate through SSO, while agents get their own credential model and governed connection policies.
What is the difference between a guardrail and a policy in this context? Policies are operational controls: rate limits, time-based access windows, geographic restrictions, spend caps. Guardrails are content-level controls: semantic rules about what an agent may request and what it may return. Both are applied to each connection, but they operate at different layers — policies on the metadata of the interaction, guardrails on the substance of what is communicated.
Does every agent-to-service interaction need a separate connection definition? Yes, and that is intentional. Each connection is a named, versioned relationship between two entities with its own policy and guardrail configuration. This gives you the granularity to enforce least privilege: an agent might have broad read access through one connection and tightly restricted write access through another, with no configuration change required on the agent itself.
How does bidirectional control help prevent data exfiltration? Most security tools inspect inbound requests — they ask "is this caller authorized?" Bidirectional controls also inspect outbound responses: they ask "should this data be allowed to leave?" An agent may be fully authorized to call a tool, but the tool's response might contain PII or secrets that should not flow into the agent's context or downstream outputs. Blocking or redacting on the response path is the layer that prevents exfiltration, and it only exists if controls are applied in both directions. For more on this risk, see Data Exfiltration Risks in Agentic AI.