Getting Started
This guide walks you through the core setup path: create an account, register the components of your AI infrastructure, connect them, and test the configured controls. Start with one harmless request and confirm its identity, decision, and recorded activity before increasing traffic.
How Praesidia works, in one paragraph
Praesidia provides a workspace for the identities, connections, and controls of your AI infrastructure. Register applications, MCP servers, and agents, then configure connections, guardrails and policies for the paths you route through the platform. Discovered agents can appear as observations before they are adopted and given credentials. Recorded activity describes connected capture paths; it does not establish visibility into traffic that bypasses Praesidia.
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 the Praesidia sign-up page. 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.
Follow the credential mode returned for the entity. Managed agents may use just-in-time task capabilities; in that mode clientSecret can be null. Discovered, observed agents have no runtime credentials until adopted. When a flow issues a static credential, store it securely and plan its rotation. Revoking an identity can also affect workflows that depend on it.
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, time-based access, a monthly spend cap, approval before a task runs, and the task types, models and tools the connection may carry. See Policies.
Editing a connection's guardrails and limits needs a Team plan (Individual tier or above), and LLM-based checks need the Advanced tier; see pricing.
After updating a control, exercise an allowed and denied request on the intended path. Confirm the recorded decision and the propagation behavior for your deployment.
Step 6: Authenticate
Use the authentication flow for the selected route. For a configured OAuth client-credentials integration, request a token from your deployment's endpoint:
POST https://<your-api-host>/oauth/token
Obtain the API host and client credentials from your deployment operator. For a managed task using JIT capabilities, use that task's identity and capability context instead of inventing a static secret. Application gateway keys (pra_…), personal management keys (pk_…), OAuth tokens, and task capabilities serve different routes and are not interchangeable. See the model gateway quickstart or action evidence guide for those paths.
Step 7: Watch it run
Find your test request in the appropriate activity view and confirm the organization, identity, time and decision. Test a deliberate denial as well as a successful request. Where protected actions are enabled, continue from the action ID to its timeline and independently verified export. Configure budgets and spend alerts before expanding a paid model workload.
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? Issue replacement credentials using the entity's supported flow, update authorized consumers, and revoke the old credentials. Test dependent workflows after rotation.
Is there a free tier? Yes. Check current plan limits and the features enabled in your workspace. Protected actions, governance packs and enterprise identity features have their own access requirements; signup alone does not enable every feature.