Entity Types

Q: Can one entity be both a client and a server?

Yes — client and server are roles within a connection , not properties of the entity. An agent can be the client on its connection to an MCP server and the server on a connection where an application dispatches work to it. Each connection's direction is explicit.

Estimated reading time: 5 minutes

Praesidia registers applications, MCP servers and agents so supported routed interactions can be attributed and controlled. Authentication depends on the entity and route: application keys, managed-agent task capabilities and MCP endpoint authentication serve different purposes. Inventory registration alone does not mediate traffic that bypasses the platform.

Applications

An application is any web or mobile application in your stack. This could be a frontend app, a backend service, or a microservice.

When you register an application:

It receives a one-time application API key (pra_…); store it securely
It can be configured as a client (makes requests) or a server (receives requests) in connections
Guardrails and policies can be set for its interactions

Example: A customer-facing web application that needs to call an MCP server for AI-powered features. The application authenticates as itself — not as a borrowed service account — so its traffic, limits, and violations are attributable to it specifically.

MCP Servers

A Model Context Protocol server provides tools and resources to AI models. MCP servers are a critical part of modern AI infrastructure, exposing databases, APIs, and business logic to agents and applications.

When you register an MCP server:

Praesidia stores its endpoint and the authentication configuration you supply
Praesidia acts as the authentication and authorization layer in front of it
You can control which entities are allowed to connect and which tools they can access
During a managed agent chat turn, guardrails can check tool arguments and results; a direct MCP call does not run those content checks

Beyond the basics, registered MCP servers get an operational surface: tool listing and invocation through the platform, health monitoring, per-server rate limits, and usage analytics — so a misbehaving or degraded tool server is visible before it becomes an incident.

Example: An MCP server that provides access to a product database. You want to allow a customer agent to query products but prevent it from modifying inventory — expressed as tool-level permissions on the connection, not as hope.

Agents

An agent is an AI system that can take actions. Praesidia supports two types:

External agents: Agents running outside of Praesidia — on your infrastructure or a vendor's. You register them and manage their connections and security.
Platform agents: Agents built and hosted directly on Praesidia, with full lifecycle management from creation to monitoring.

When you register an agent:

Ordinary managed-agent creation uses JIT task capabilities and returns clientSecret: null
It can connect to applications and MCP servers
Guardrails control what it can request and what it receives
Policies set operational boundaries (rate limits, schedules, and more)

Agents carry the richest lifecycle surface of the three entity types, because they carry the most risk: versioning with rollback, attestations (verifiable claims about the agent that feed its trust standing), drift detection against expected behavior, heartbeat liveness for long-running agents, and a per-agent trust score that other controls — like a connection's minimum-trust requirement — can gate on. Agents can also verify domain ownership via DNS, which strengthens the identity claim behind agent-to-agent communication.

Example: An AI agent that processes customer support tickets. It connects to a CRM MCP server and a knowledge-base MCP server, with guardrails preventing it from accessing financial data, a rate limit bounding its call volume, and a trust-score history that would surface behavioral drift.

Entity credentials

Authentication depends on the entity and route:

Creating an application returns a one-time pra_… application API key.
Managed agents created in the console or ordinary API flow use JIT task capabilities and return clientSecret: null.
MCP registration stores an endpoint and supplied authentication configuration; it does not issue a universal client secret.
OAuth dynamic registration is a separate flow that returns client_id and client_secret for supported OAuth routes.

Use the authentication flow documented for your route. Application gateway keys, personal management keys, OAuth tokens and task capabilities are not interchangeable. Store issued secrets securely, rotate them through the supported flow, and test dependent workflows after revocation. Propagation depends on the enforcement path; see the model gateway quickstart and runtime security.

Choosing the right entity type

A practical rule: register the component as what it is to the traffic, not what it contains. A backend service that happens to call an LLM is still an application; an autonomous system that decides which tools to call is an agent; anything that exposes tools over MCP is an MCP server. The distinction matters because the lifecycle surfaces differ — agents get versioning, attestations, drift detection, and trust scoring; MCP servers get tool-level controls and health monitoring — and picking the right type gets you the right controls by default.

Common questions

Can one entity be both a client and a server? Yes — client and server are roles within a connection, not properties of the entity. An agent can be the client on its connection to an MCP server and the server on a connection where an application dispatches work to it. Each connection's direction is explicit.

Should each instance of my service be its own entity? Usually one entity per logical component is right for applications and MCP servers. For agents, consider the revocation question: the smallest unit you would want to revoke independently should have its own identity. High-sensitivity agents often warrant per-instance registration; fleets of identical low-risk workers often do not.

What is the difference between an external agent and a platform agent? Where it runs and how much lifecycle the platform manages. External agents run anywhere; Praesidia governs their identity, connections, and controls. Platform agents are additionally built and hosted on Praesidia, so versioning, deployment, and monitoring are managed end to end.

Do entities from different organizations ever see each other? No — entities, connections, logs, and analytics are scoped to the owning organization. Cross-organization interaction is possible only through explicitly declared and approved relationships, never by default.