Getting Started
Welcome to Praesidia. This guide walks you through the core setup path: create an account, register the components of your AI infrastructure as entities, connect them, and put controls on the connection. By the end you will have one governed, authenticated, observable link between two components — the pattern everything else on the platform builds on.
How Praesidia works, in one paragraph
Praesidia is a control plane that sits between the pieces of your AI infrastructure. Every component — application, MCP server, or agent — is registered as an entity with its own credentials. Entities communicate through explicitly created connections, and each connection carries its own controls: guardrails (content-level rules on what can be communicated) and policies (operational rules like rate limits and geographic restrictions). Every authenticated interaction is logged, so you get attribution and audit evidence as a by-product of normal operation rather than as a separate project.
Prerequisites
- A Praesidia account (sign up free — there is a $0 free tier)
- At least two entities to connect (applications, MCP servers, or agents)
Step 1: Create your account
Visit app.praesidia.ai and sign up. Your account belongs to an organization — the tenant boundary for everything you create. You can invite teammates with role-based permissions later, and enable MFA on your own account from the profile security settings; organizations can also enforce security policies (session, password, MFA requirements) org-wide.
Step 2: Register an entity
Navigate to the dashboard and register your first entity. You can register:
- Application: A web or mobile app, backend service, or microservice that needs to call AI services.
- MCP Server: A Model Context Protocol server you want to secure — Praesidia becomes its authentication and authorization layer.
- Agent: An AI agent. External agents (running anywhere) are registered and governed; platform agents are built and hosted on Praesidia with full lifecycle management.
Each entity receives a unique set of credentials: a client key and client secret. Store these securely — a secrets manager, not a config file. Per-entity credentials are what make revocation surgical: disabling one entity never disrupts the others.
Step 3: Register a second entity
Connections link exactly two registered entities, so register the other half of your interaction pair — for example, the MCP server your application (or agent) will call.
Step 4: Create a connection
Navigate to Connections and create a new connection between your two entities. Specify:
- Which entity is the client (initiates requests)
- Which entity is the server (receives requests)
Connections are directional and explicit. Two entities in the same account cannot communicate until a connection exists between them — there is no implicit trust from co-tenancy. If both directions are needed, create two connections.
Step 5: Configure controls
Optionally — but in production, actually — add controls to the connection:
- Guardrails: content-level rules evaluated on the requests and responses flowing through the connection — pattern rules, PII detection and redaction, and LLM-based checks. See Guardrails.
- Policies: operational rules — rate limits, geographic restrictions, volume caps, time-based access, IP allowlists. See Policies.
Controls can be updated at any time without re-issuing credentials or restarting services; changes take effect on the next request.
Step 6: Authenticate
Use your entity credentials to authenticate through Praesidia's OAuth2 endpoint:
POST https://auth.praesidia.ai/oauth/token
Include the client key and secret (client credentials grant) to receive a short-lived access token, and use that token on requests between connected entities. Tokens expire and are re-requested programmatically — the long-lived secret never travels on regular traffic.
Step 7: Watch it run
With traffic flowing, the platform starts producing the operational surface: the dashboard shows activity across your entities, connection monitoring shows request volumes and any guardrail or policy violations, and the audit log records every authenticated interaction with the identity that performed it. This is a good moment to explore budgets and spend alerts if your entities call paid model APIs — cost controls attach to the same identities you just created.
Common questions
Do I need all three entity types to start? No — you need any two entities to form a connection. The most common first pair is an application or agent (client) connecting to an MCP server (server). Add more entity types as your architecture grows; the pattern stays the same.
Can two entities in my account talk to each other without a connection? No. Connections are explicit and directional by design — registering an entity grants it an identity, not access. This zero-trust default means adding a new component never silently widens what your existing components can reach.
What happens if I lose a client secret? Rotate it: issue new credentials for the entity and update the one place that stores them. Because credentials are per-entity, rotation and revocation affect only that entity — nothing else in your account is disturbed.
Is there a free tier? Yes — you can sign up and run the full quickstart on the $0 free tier. Paid plans add capacity and enterprise features (SSO, SCIM, custom roles) when you need them.