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 manages three types of entities. Each represents a component in your AI infrastructure that needs to communicate securely with other components — and each becomes a first-class principal: it holds its own credentials, appears in the audit trail under its own identity, and carries its own controls. Nothing in the platform shares identities, because shared identities make attribution ambiguous and revocation blunt.

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 client key and client secret
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:

It receives credentials for authentication
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
Content-aware guardrails can filter requests and responses in both directions

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:

It receives credentials like any other entity
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

Every entity receives:

Client key: A public identifier for the entity
Client secret: A private key used for authentication

Use these credentials to authenticate through Praesidia's OAuth2 endpoint:

POST https://auth.praesidia.ai/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_CLIENT_KEY
&client_secret=YOUR_CLIENT_SECRET

The response includes a short-lived access token to use on subsequent authenticated requests. The design keeps the long-lived secret off the wire: it is presented only to the token endpoint, while regular traffic carries expiring tokens. Revoking an entity invalidates its credentials immediately — and because credentials are per-entity, the revocation touches nothing else in your account.

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.