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 the post on how to give an AI agent its own identity.
Connection-centric security
A more effective approach secures the connections between entities rather than the entities themselves.
In Praesidia, an agent reaches another agent, or an MCP server's tools, over a defined connection, and traffic that does not pass through Praesidia is not governed or recorded by it. Praesidia applies 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, time-based access windows, and spend caps.
Guardrails apply in both directions: on a connection between two agents, they check the task one agent sends and the result the other sends back, and when an agent running on Praesidia calls an MCP tool during a chat turn, they check the call's arguments before it is sent and its result before the model reads it. A tool called directly through the Praesidia API is not checked by guardrails. Policies are enforced once, when a task between agents is dispatched; MCP tool calls have their own checks instead, including per-tool permissions on the agent's connection and per-tool rate limits. This is not just authentication: it governs the content and the operation of the traffic that passes through Praesidia. 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 has to cover applications, MCP servers, and agents, though each takes part in it differently:
- Applications register and receive an API key with scopes, such as calling agents or reading connections. By default an application may call only the agents on its list, and the list starts empty. Praesidia also creates a client agent for each application; connections belong to agents, so an application's connections are that agent's, and its key can be pinned to some of them.
- MCP servers are registered with Praesidia, which can store the server's credentials and use them on the calls it makes, so an agent calling through Praesidia does not need them. Through Praesidia, an agent needs an active connection to the server, and the connection's per-tool permissions, plus the agent's tool rules in enforce mode, decide which tools it may call. A client that calls the server directly, outside Praesidia, meets only the server's own authentication.
- Agents can be external services or built and hosted directly on the platform.
The primitives differ by type: an agent can have client credentials of its own and holds the connections, an application has an API key, scopes and a list of agents it may call, and an MCP server has the credentials Praesidia uses to reach it and per-tool rate limits.
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 an audit trail of the decisions Praesidia makes on the traffic that passes through it. Calls that do not pass through Praesidia are not recorded.
For a broader view of the threat landscape, the AI agent security 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 the MCP server governance guide.
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, spend caps. Guardrails are content-level controls: semantic rules about what an agent may request and what it may return. On a connection between two agents both are checked on each task, at different layers — policies on the metadata of the interaction, guardrails on the substance of what is communicated. The connection policy does not apply to an agent's MCP tool calls, which have per-tool rate limits instead.
Does every agent-to-service interaction need a separate connection definition? Yes, and that is intentional. Through Praesidia an agent sends tasks to another agent only over a connection between the two, and calls an MCP server's tools only over its active connection to that server. Each connection is a relationship between two entities with its own policy and guardrail configuration: the policy governs the tasks sent to another agent, and a connection to an MCP server carries per-tool permissions that can deny a tool or cap its calls per hour. 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.